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INTRODUCTION  .  . 

\  //*  " 

The  research  covered  by  this  final  I  report  has  two  principal 
objectives.  One  is  the  development  of  methods  and  tools  for  the  design  and 
evaluation  of  SECURE  SYSTEMS.  The  other  is  the  development  of  systems  for 
AUTOMATIC  PROGRAMMING  with  emphasis  on  programs  for  specifying,  designing, 
and  optimizing  programs.  In  this  area *wc  are- concerned  both  with  specialized 
systems  for  restricted  domains  and  with  the  development  of  more  general 
KNOWLEDGE-BASED  SYSTEMS,  p  __ 

The  various  projects  in  our  research  program,  and  the  senior 
investigators  in  each  project  are  listed  below: 

A.  SECURE  SYSTEMS 

(A.l)  Protection  and  Integrity  of  Data  Bases 
(Naftaly  Minsky) 

(A. 2)  Architectural  Features  for  Operating  System  Security 
(Manfred  Ruschitzka) 

B.  AUTOMATIC  PROGRAMMING 

B.l  Studies  and  Systems  in  Specific  Domains 

CB. 1.1)  Automatic  Optimization  of  Programs  Defined  as 
Finite  State  Machines 
(Edward  Wilkens) 

(B.l. 2)  Programs  for  Computer  Aided  Formulation  and 
Improvement  of  Recursively  Defined  Algorithms 
(Marvin  Pauli) 

(B.l. 3)  Computer  Aided  Design  of  Specialized  Efficient 
Algorithms  for  Sorting  and  Selection  Problems 
(Saul  Levy) 

(B.l. 4)  Automatic  Program  Formation  from  Problem  , 

Specifications  i 

(Saul  Amarel ) 

(B.2)  Knowledge  Based  Systems:  The  Meta  Description  System  MDS 
(Chitoor  V.  Srinivasan) 
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I.  PROJECT  SUMMARIES 


A  summary  status  of  each  project  is  presented  in  this  section. 
It  is  mainly  intended  as  a  guide  to  the  collection  of  technical  documents 
that  constitute  the  body  of  the  present  report;  it  also  outlines  the  main 
achievements,  the  current  state  of  work,  and  the  implementation  status  of 
computer  systems  developed  in  each  of  the  projects. 


(A. 1 )  Protection  and  Integrity  of  Data  Bases 

The  general  objective  of  this  research  has  been  the  development 
of  a  protection  theory  which  is  suitable  for  the  protection  of  the  security 
and  the  semantic  integrity  of  databases.  This  objective  has  been  achieved 
by  means  of  the  new  operation-control  (OC)  protection  scheme,  described  in 
(Minsky,  1976d,  1976e,  1977a)*.  The  new  scheme  is  superior  to  the  standard 
schemes  in  many  ways:  it  has  more  expressive  power,  it  is  more  efficient, 
more  stable  and  easier  to  prove  and  review.  In  the  context  of  the  new 
scheme  we  attacked  a  number  of  old  and  new  protection  issues.  In 
particular:  the  principle  of  attenuation  of  privileges  (Minsky,  1977d), 
and  revocation  problems  (Minsky,  1977a),  cooperative  authorization  (Minsky, 
1977b),  "secure-information  flow"  (Minsky,  1976c),  and  others.  We  studied 
the  application  of  our  scheme  in  a  number  of  specific  domains,  such  as: 
privacy  protection  and  its  "intentional  resolution"  (Minsky,  1976  a), 
networks,  management  and  auditing  of  financial  systems  (Minsky,  1976e  and 
1977c). 


Fifteen  publications  covering  work  in  this  area  are  included  in 
the  present  final  report. 

Most  of  the  work  has  been  theoretical;  however,  it  was  supported 
by  two  major  system  development  activities: 

a)  A  system  which  implements  "files  with  semantics". 

(This  was  written  in  SIMULA  and  is  now  completed.) 

b)  An  experimental  database  system  based  on  the  OC  scheme. 

(This  system  has  not  yet  been  finished  but  parts  of  it 
are  working.) 


(A. 2)  Architectural  Features  for  Operating  System  Security 

The  main  thrust  of  our  research  effort  in  the  area  of  Secure 
Operating  Systems  resulted  in  the  definition  of  a  novel  protection  mechanism 
which  attempts  to  combine  the  advantages  of  the  capability  and  access  control 
list  schemes  and  to  minimize  their  limitations.  The  properties  of  this 
mechanism  (Ruschitzka,  1977a)  have  been  studied  in  the  context  of  a 

•keterences  are  ns  ted  in  Section  II  below  (List  of  Publications). 


simulation  which  is  based  on  the  design  of  an  educational  computer  system 
(Ruschitzka,  1977b).  This  system  is  characterized  by  an  integrated 
design  philosophy  with  respect  to  the  hardware  architecture  (Ruschitzka, 
1977c,  1977d),  the  implementation  language  (Ruschitzka,  1977e),  and  the 
operating  system  (Ruschitzka,  1977f). 

The  protection  of  information  resources  depends  on  their  secure 
management.  Our  work  on  Secure  Operating  Systems  has  been  influenced  by 
our  earlier  efforts  in  research  management,  in  particular  scheduling,  which 
have  continued  in  parallel. 

Eight  articles  covering  work  in  this  project  are  included  in 
the  present  final  report.  Two  of  these  (Ruschitzka,  1977g,  1977h)  are  in 
the  area  of  scheduling,  and  they  are  included  to  reflect  the  overall  scope 
of  our  activities  in  this  project. 


This  research  has  achieved  positive  results  in  two  areas,  the 
building  of  an  optimizer  for  the  efficient  encoding  of  finite  state  machines, 
and  the  definition  and  implementation  of  a  specification  language  for  finite 
state  machines. 

The  primary  thrust  of  the  work  on  an  optimization  program, 
which  has  been  the  subject  of  most  of  the  effort  in  this  area,  has  been  to 
produce  a  program  which  can  optimize  finite  state  machines  built  by 
practitioners  of  practical  programming,  rather  than  toy  state  tables  de¬ 
signed  to  exemplify  the  techniques.  Such  practical  state  tables  should  have 
a  range  of  inputs  times  states  product  in  the  area  of  fifty  to  one  thousand. 
When  this  product  is  above  one  thousand,  and  preferably  even  less,  principles 
of  good  modularization  suggest  that  a  composite  of  several  such  state  tables 
be  used. 

Part  of  the  objective  of  this  work  was  to  extend  the  switching 
theoretic  partition  methods  to  include  such  practical  considerations  as 
don't  care  values  in  the  state  table.  Switching  theory  has  not  been  found 
applicable  in  the  past  to  problems  of  realistic  size,  without  including 
such  difficulties  as  don't  cares.  The  approach  taken  was  to  define  con¬ 
structs  that  had  most  of  the  mathematical  properties  of  partitions,  but  to 
sacrifice  elegant  properties  to  the  more  pragmatic  goal  of  achieving 
solutions  to  large  programs. 

An  algorithm  was  developed  based  around  these  partition  theory 
techniques  that  uses  a  very  complex,  highly  pruned  search  for  an  optimal 
solution.  The  search  is  ordered  in  such  a  way  that  when  a  solution  is 
found  it  is  optimal  under  the  criteria  used.  This  algorithm  is  described 
partially  in  (Wilkens,  1977a).  This  paper  describes  the  algorithm  as  it 
was  when  it  was  first  able  to  find  solutions  to  small  state  tables.  The 
algorithm  as  presently  implemented  is  at  least  ten  times  faster  than  the 


original  algorithm.  The  speed-up  is  due  to  increased  pruning  of  the 
search  tree  by  some  as  yet  unreported  techniques.  This  final  algorithm 
approaches  the  goal  of  solving  practical  sized  problems  by  completing  state 
tables  with  sizes  of  96  and  120  entries  in  7.2  and  16  seconds  respectively 
on  an  IBM  370/168.  However,  it  did  not  complete  state  tables  of  size  297 
or  616  in  2  minutes  on  this  machine.  The  larger  state  tables  we  have  been 
using  for  tests  have  been  drawn  from  the  applications  literature,  rather 
than  artibrarily  constructed  state  tables.  This  accounts  for  the  lack  of 
a  large  number  of  samples  on  which  to  evaluate  the  overall  performance  of 
the  algorithm.  The  search  traces  of  the  two  incomplete  state  tables 
suggests  still  further  pruning  techniques  that  might  be  applied. 

In  summation,  the  results  of  this  work  suggest  that  realistic 
sized  state  tables  can  be  optimized.  Further,  the  techniques  used  may  be 
more  broadly  applied  to  different  criteria  of  optimality.  In  addition,  by 
the  level  of  success  in  finding  a  solution  to  optimization,  it  is  reasonable 
to  conclude  that  sub-optimal,  good  solutions  can  be  found  with  less  develop¬ 
ment  effort  and  less  computer  time. 

The  Finite  State  Specification  Language  devel oped  as  part  of 
this  work  provides  a  powerful  yet  simple  to  learn  language.  Since  it  is 
based  around  the  concept  of  a  finite  state  machine,  it  is  of  potential  value 
to  the  hardware  designers  who  are  increasingly  forced  to  learn  micro¬ 
processor  assembly  language.  The  use  of  this  language  removes  most  of  the 
programming  from  the  task,  since  only  a  state  table  is  necessary.  The 
language  is  described  in  (Wilkens,  1977b),  and  more  fully,  and  with  more 
description  of  its  incorporation  into  a  system  in  (Wilkens,  1977c). 

The  above  described  programs  have  been  coupled  with  a  small 
program  that  runs  on  a  PDP-10  to  combine  the  outputs  of  the  language  and 
optimizer  and  produces  assembly  code  with  the  encoded  finite  state  machine 
and  its  interpreter  ready  to  be  assembled  and  run  on  a  PDP  11.  The 
machine  dependent  (PDP-11)  part  is  about  a  page  of  fortran  code.  Therefore 
this  is  easily  adapted  to  other  target  computers. 

Three  papers,  covering  work  in  this  area,  are  included  in  the 
present  final  report. 


(B.1.2) 


Our  objective  has  been  to  develop  a  system  which  will  aid  a 
user  in  the  specification  of  a  recursive  definition  for  an  enumeration- 
based  algorithm,  and  then  to  provide  the  user  with  one  or  more  'good' 
algorithms  that  implement  the  definition  and/or  suggestions  for  reformulat¬ 
ing  the  initial  definition.  Our  research  in  this  area  produced  several 
theoretical  results  which  provided  the  basis  for  building  a  small  experi¬ 
mental  system  which  transforms  a  given  recursive  definition  into  efficient 
code. 


Programs  for  Computer-Aided  Formulation  and  Improvement  of 
Recursively  Defined  Algorithms 


In  (Pauli,  1977a,  1977b)  an  attempt  is  made  to  formally  and 
succinctly  state  and  prove  a  number  of  relations  between  recursive 
definitions  and  their  implementations,  including  the  significance  of  the 
'uniform  inverse'  in  allowing  storage  savings,  and  of  transformations  which 
convert  a  recursive  definition  into  a  set  of  equations  which  can  be  solved 
speedily. 

In  (Pauli,  1977c,  1977d)  we  present  a  generalization  of  the 
principle  which  allows  the  time  efficient  implementation  of  the  shortest 
path  problem  (Dikstra's  algorithm).  This  principle  is  applied  to  two 
problems  involving  solutions  of  sets  of  equations  and  it  yields  algorithms 
more  efficient  than  those  currently  known. 

The  experimental  system  which  we  constructed  consists  of  the 
following  programs: 

OFN.SNO.  A  SNOBOL  program  3300  statements)  which  takes  as 
input  a  recursive  definition;  it  searches  for  'uniform  inverse' 
and  other  properties,  and  it  produces  an  output  program  to 
implement  the  given  definition. 

SIM. SNO.  A  SNOBOL  program  (^  1000  statements)  which  simulates 
the  recursive  definition  for  sample  inputs  and  produces  the 
resultant  output. 

CHART. SNO.  A  SNOBOL  program  500  statements)  which  makes 
flowchart  representations  of  output  of  OFN.SNO. 

INF. SNO.  A  SNOBOL  program  (^  200  statements)  which  contains 
descriptions  and  instructions  on  use  of  OFN.SNO. 

Four  papers  covering  work  in  this  project  are  included  in  the 
present  final  report. 


(B.1.3)  Computer  Aided  Design  of  Specialized  Efficient  Algorithms  for 
Sorting  and  Selection  Problems 

This  research  was  directed  to  the  automatic  generation  of 
algorithms  for  solving  a  class  of  problems  involving  the  order  of  a  given 
set  of  numbers.  The  progress  in  this  report  is  described  in  (Levy,  1977). 

We  produced  two  ILISP  programs,  NAA  and  NAA1,  which  generate 
good  and  extremely  good  programs  (respectively)  for  determining  order 
statistics.  In  response  to  the  request  "Find  the  I-th  out  of  R  numbers" 

NAA  produces  all  'reasonable'  candidate  programs  and  selects  the  best 
among  them.  NAA1  is  a  refinement  on  NAA  which  not  only  produces  the  best 
programs  generated  by  NAA  but  also  uses  certain  heuristics  which  enables  it 
to  produce  more  human-like  programs;  in  fact  for  all  the  examples  which  we 
have  tried  NAA1  had  produced  the  best  programs  known  for  the  solution  of 
those  problems. 
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We  started  working  on  two  additional  aspects  of  the  problem: 
producing  a  better  interface  to  the  NAA  programs  (more  intelligible 
output),  and  an  approach  to  the  generation  of  programs  for  the  solution  of 
order  statistics  problems  in  the  presence  of  additional  information  about 
the  input  set  (e.g.,  find  the  I-th  largest  of  (a,  b,  c,  d,  e,  ....  h)  given 
that  it  is  not  c,  d,  or  h).  We  are  concerned  with  the  assimilation  of  the 
information  into  the  program  generating  process  and  consider  this  a  key 
problem  in  the  design  of  a  man-machine  interactive  program-generating 
system.  Work  in  this  area  did  not  reach  yet  the  state  of  documentation. 

One  report  covering  work  in  this  project  is  included  in  the 
present  final  report. 


(B.1.4)  Automatic  Program  Formation  from  Problem  Specification 

The  long  term  objective  of  this  research  is  to  understand 
the  interactions  between  knowledge  representations  and  reasoning  strategies 
in  program  synthesis  problems.  In  our  work  (which  is  also  supported  by 
NIH  as  part  of  the  Rutgers  Research  Resource  on  Computers  in  Biomedicine) 
we  considered  several  forms  of  specification  for  the  program  systhesis 
problem;  but  the  emphasis  has  been  on  specifications  in  the  form  of  a 
finite  number  of  input/output  correspondences. 

We  developed  a  strategy  which  combines  a  model -guided  global 
approach  to  search  for  a  program  with  a  local  approach  which  focuses  on 
detailed  modifications  of  a  program  based  on  analysis  of  its  performance. 

To  test  this  strategy,  we  started  to  implement  a  computer  system  (in 
LISP  1.6)  which  we  called  TF.  Our  main  effort  in  this  project  over  the 
last  1%  years  was  directed  to  representations  in  TF  and  to  subsystems  for 
acquiring  knowledge  and  for  building  and  managing  the  knowledge  base  of  TF. 
The  growth  in  size  and  complexity  of  TF  (which  occupies  now  a  core  image  of 
about  120K  words  in  a  PDP-10)  induced  us  to  direct  attention  to  several 
problems  of  large  system  development.  Because  of  the  relatively  small 
level  of  effort  directed  to  this  project  and  the  unexpected  requirements  of 
the  system  building  task,  we  did  not  reach  as  yet  a  stage  where  our  program 
formation  strategies  could  be  studied  experimentally.  We  plan  to  continue 
work  in  this  area,  and  expect  to  produce  reports  documenting  the  TF  system 
and  related  studies  in  program  formation  within  about  a  year. 


(B.2)  Knowledge  Based  Systems;  The  Meta  Description  System  MDS 

MDS  proposes  a  new  way  of  organizing  intelligent  systems  and 
a  new  approach  to  Automatic  Programming- -where  knowledge  in  a  domain  is 
used  to  construct  programs  from  vague  specifications  of  their  requirements. 
We  call  this  "Knowledge  Based  Programming"  (Srinivasan,  1973b).  In 
constructing  programs  in  a  domain  and  in  using  the  domain  knowledge,  MDS 
can  learn  from  its  experience  in  a  domain  and  improve  its  performance. 
Establishing  the  logical  foundations  of  these  processes  for  knowledge 
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handling  and  utilization  has  been  the  major  contribution  of  our  work  in  this 
project.  Details  of  these  processes  are  discussed  in  (Srinivasan,  1977). 

This  is  the  principal  report  which  summarizes  the  progress,  the  key  contribu¬ 
tions  and  the  significance  of  work  in  MDS.  Problems  are  classified  in  MDS 
as  belonging  to  one  or  more  of  the  following  categories:  Assimilation, 
Planning,  Recognition,  Goal  Seeking,  Theorem  Proving,  and  Language 
Understanding. 

Our  recent  work  on  Theorem  Proving  (Sandford,  1977a,  1977b) 
establishes  the  logical  basis  for  using  model  based  reasoning  to  guide 
theorem  proving  search.  It  also  presents  a  new,  sound  and  complete 
resolution  refinement  strategy,  called  Hereditary  Lock  Resolution. 

The  MDS  formalism  for  describing  domain  knowledge  has  been 
applied  to  several  tasks.  Applications  to  banking  and  medicine  are  described 
in  (Srinivasan,  1974)  and  (Irwin  and  Srinivasan,  1976).  A  system  which  is 
a  specialization  of  MDS  for  research  in  action  interpretation  problems  was 
developed  in  the  framework  of  our  NIH-supported  Research  Resource  on 
Computers  in  Biomedicine  and  it  is  being  applied  to  work  in  modeling 
Belief  System  (the  system  is  called  AIMDS).-  For  the  period  1973  to  1976, 
research  on  MDS  was  jointly  supported  by  the  ARPA  grant  and  by  the  NIH 
grant. 


Considerable  progress  was  made  towards  the  implementation  of 
MDS.  Major  parts  of  the  system  have  been  written  in  INTERLISP.  System 
development  proceeded  at  ISI  and  at  SUMEX-AIM  through  the  ARPANET.  At 
present  the  system  is  at  SUMEX-AIM.  The  current  status  of  the  implementation 
may  be  summarized  as  follows:  The  "Domain  Definition"  system  is  now  ready. 
This  is  the  subsystem  that  enables  a  user  to  define  "Structural",  "Sense", 
and  "Transformational"  knowledge  in  a  domain  and  have  the  system  create 
compact  representations  of  these  definitions  in  the  model  space  for  the 
defined  domain.  The  second  subsystem  that  is  now  operational  is  the 
"Dimensional  Consistency  Check"  system.  This  checks  the  given  domain 
definitions  for  "Structural  Consistency"  and  builds  a  dictionary  of  all 
possible  interactions  that  can  occur  in  the  model  space  of  the  domain, 
between  properties  of  various  instantiated  models,  and  for  each  such  inter¬ 
action  between  pairs  of  properties  of  objects,  builds  the  conditions  under 
which  the  interaction  would  occur.  To  complete  the  model  space  management 
system  it  is  still  necessary  to  complete  the  so  called  "Domain  Compiler". 
Based  on  the  domain  definitions  and  the  interactions  between  the  various 
objects  in  the  domain  and  the  conditions  on  the  interactions,  the  domain 
compiler  compiles  LISP  code  for  the  instantiation  of  the  various  objects  and 
relations  in  the  model  space,  and  for  the  access  and  updating  of  the  objects 
and  relations.  The  compiled  code  has  two  parts:  one  for  the  creation  and 
updating  of  models  in  the  model  space;  and  the  other  for  the  checking  of 
consistency  of  the  model  space  itself.  We  have  now  devised  a  scheme  for 
compiling  the  consistency  conditions.  Most  of  the  code  for  the  model 
space  compiler  has  now  been  written.  The  various  parts  of  this  code  should 
now  be  debugged  and  properly  integrated.  We  expect  to  complete  the 
remaining  tasks  of  the  implementation  in  1978  (which  is  beyond  the  period 
of  the  current  grant). 
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Financial  Summary 

Research  on  Secure  Systems  and  Automatic  Programming 


I.  Financial  Status 

A.  Total  funds  allocated  for  the  period 
March  1,  1973  to  August  30,  1977 

B.  Expenditures  during  period 

March  1,  1973  to  June  29,  1974  $  92,226. 

Expenditures  during  period 

June  30,  1974  to  August  31,  1977  461,875. 


Total  expenditures  for  the  period 

March  1,  1973  to  August  31,  1977  $554,101. 

Difference 


II.  Summary  breakdown  of  the  expenditures  for  the  last  rep 
period  of  the  grant  (June  30,  1977  to  August  31,  1977) 


Total 

Expenditures 

Expenditures 

This  Period 

7/1/74  to 

6/30/77  to 

6/29/77 

8/31/77 

PERSONNEL: 

Faculty 

Levy,  S. 

$  12,221 

$  2,450 

Minsky,  N. 

10,559 

4,228 

Morgenstem,  M. 

- 

1,770 

Pauli,  M. 

18,070 

- 

Ruschitzka,  M. 

6,810 

3,910 

Srinivasan,  C.  V. 

8,856 

- 

Wilkens,  E. 

11,742 

- 

$  68,258 

$  12,358 

Adjuncts 

Morrell,  L. 

1,616 

- 

Groeber,  B. 

1,186 

- 

Anand,  P. 

4,373 

- 

$  7,175 

- 

$554,185. 


.54,101. 

84. 


Total 

Expenditures 
7/1/74  to 
8/31/77 


$  14,671 
14,787 
1,770 
18,070 
10,720 
8,856 
11,742 

$  80,616 


1,616 

1,186 

4,373 

$  7,175 
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Total  Expenditures  Total 

Expenditures  This  Period  Expenditures 
7/1/74  to  6/30/77  to  7/1/74  to 

6/29/77  8/31/77  8/31/77 

Research  Assistants 


Brutman,  N. 

Chen,  D. 

Dowuona,  N. 

Goegelman,  M. 

Griffin,  G. 
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ON  THE  SECURITY  OF  DATA  BASE  SYSTEMS 


N.  Minsky 


Abstract :  Two  aspects  of  security  in  data  bases  are  discussed 
in  this  paper:  the  description  of  the  security  state a  and  its 
enforcement  mechanism.  The  conventional  approach  to  these  two 
aspects  has  been  found  inadequate  ,  and  a  new  approach  has 
been  proposed.  According  to  the  proposed  approach,  the  user's 
program  which  interacts  with  the  data  base  is  controlled  by  a 
set  of  rules,  collectively  called  schema ,  whose  function  is  to 
authorize  the  operations  performed  by  the  user.  The  schema  has 
no  authority  over  information  which  is  not  related  to  the  data 
base,  but  it  can  restrict  the  way  in  which  information  from  the 
data  base  is  manipulated  even  when  such  information  is  in  the 
user's  working  space. 
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ON  THE  SECURITY  OF  DATA  BASE  SYSTEMS 
N.  Minsky 


1.  Introduction 

It  is  customary  to  distinguish  between  two  aspects  of  security  of  data 
bases,  their  integrity  and  privacy.  Although  this  classification  will  not  be 
essential  to  this  paper,  we  will  use  it  in  order  to  introduce  the  subject. 

In  order  to  maintain  the  integrity  of  any  system,  one  must  first  have  a 
definition  of  what  the  proper  state  of  this  system  is.  This  obvious  observa¬ 
tion  raises  the  question  of  how  data  bases  are  defined.  Being  a  dynamic  system, 

» 

it  is  clear  that  a  data  base  cannot  be  defined  just  by  specifying  its  informa¬ 
tion  content  at  a  certain  moment  in  time;  there  must  also  be  a  set  of  rules 
which  specify  the  behavior  of  the  data  base  under  interaction  with  the  outside 
world.  For  example,  it  is  not  enough  to  know  that  there  is  an  entity  called 
"number-of-employees"  in  a  data  base;  it  must  be  formally  specified  that  this 
entity  should  always  be  equal  to  (say)  the  number  of  "employee"  records  in  the 
data  base. 

Unfortunately,  this  is  not  the  approach  employed  by  contemporary  data¬ 
base  systems.  In  most  of  these  systems  one  cannot  even  specify  the  scope  of 
an  entity,  not  to  mention  the  ability  to  formulate  general  rules  of  behavior. 

The  dynamic  behavior  of  the  data  base  under  these  systems  is  defined,  de  facto, 
by  the  users'  programs  which  interact  with  it. 

There  is  obviously  no  hope  for  providing  integrity  for  data  bases  as  long 
as  this  approach  prevails.  The  behavior  of  the  data  base  should  not  be  con¬ 
trolled  by  users'  programs.  On  the  contrary,  the  interaction  of  users'  programs 
with  a  data  base  should  be  under  the  jurisdiction  of  a  set  of  rules  built  into 


the  data  base  itself. 
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Privacy  has  to  do  with  the  right  of  a  user  to  perform  certain  operations 
on  the  data  base.  (The  right  to  receive  information  from  the  data  base  is 
the  most  publisized  aspect  of  privacy,  but  it  is  not  the  only  one.)  This 
implies,  again,  that  there  is  a  set  of  rules  in  the  data  base  which  dictate 
the  ways  in  which  users  can  interact  with  it. 

Thus,  privacy  and  integrity --as  different  as  their  objectives  may  be¬ 
have  one  thing  in  common:  they  both  impose  restrictions  on  the  way  in  which 
users  interact  with  the  data  base.  The  form  of  these  restrictions,  and  their 
enforcement,  are  the  subject  of  this  paper. 

The  main  thesis  of  this  paper  would  be  that  privacy  and  integrity  of 
data  bases  cannot  be  secured  very  well  just  by  imposing  restrictions  on  the 
information  which  flows  into  the  data  base  and  out.  It  will  be  argued  that 
some  control  must  be  exerted  on  the  users'  programs  which  manipulate  this 
information.  A  model  for  user  data-base  interaction,  which  allows  for  such 
a  control,  will  be  proposed.  It  should  be  pointed  out  at  the  outset  that 
the  objective  of  this  preliminary  paper  is  not  to  present  final  results,  but 
rather  to  point  out  to  difficulties  in  the  conventional  approach  to  security, 
and  to  suggest  an  alternative  approach. 


2.  A  Critical  Review  of  Conventional  Approaches 


When  discussing  security,  it  is  sometimes  useful  to  distinguish  between 
the  following  two  aspects  of  it:  (a)  The  specification  of  the  security  state , 
by  which  we  mean:  the  method  used  to  specify  the  security  measures  to  be 
imposed,  (b)  The  enforcement  of  the  security  state.  We  will  try  to  evaluate 
some  conventional  approaches  to  security  in  terms  of  these  two  aspects. 


2.1  On  the  Specification  of  Security  States 

The  prevailing  approach  to  the  specification  of  the  security  state  of 
systems  is  essentially  the  following:  Assuming  that  there  is  a  finite  number 
of  objects  in  the  system,  and  that  there  is  a  finite  set  of  potential  users 
(or  classes  of  them],  all  we  have  to  do  is  to  specify  which  actions  can  every 
one  of  the  users  apply  to  every  object.  One  way  to  represent  that  is  by 
means  of  a  matrix  [Con. 72,  Grh.72,  Lam. 71].  The  element  a^j  of  such  an 
"access  matrix"  is  the  set  of  actions  (typically  called  "accesses")  which 
user  i  can  apply  to  object  j.  Although  this  access-matrix  model  is  usually 
considered  to  be  conceptually  complete ^  it  is  obviously  not  always  practical. 

A  mathematically  equivalent  model,  which  is  often  more  convenient,  is  the 
environment  model  ^  which  had  been  recently  elaborated  by  Anita  Jones  [Jon. 73]. 
According  to  this  model ,  every  user  who  interacts  with  the  system  operates  within 
certain  environment  E  which  is  defined  by  a  set  of  pairs  {(a,p)},  where  P  is 


(1)  In  its  complete  form,  the  matrix  elements  a^  in  this  model  include 

the  condition  under  which  user  i  has  this  access  to  object  j.  But  our 
criticism  of  the  model  is  independent  of  such  a  condition. 

(2)  Also  called  the  "capability  model." 


an  object  in  the  system  and  a  is  the  action  (access)  which  the  user  is  allowed 
to  epply  to  p.  (The  pair  (a,p)  is  called  access-right .) 

Although  this  approach  may  be  adequate  for  operating  system;  it  is  not 
general  enough.  To  see  that,  consider  an  operation  A  which  a  given 
user  wants  to  perform.  Using  Jones'  environment  model ,  A  would  be  a  legal 
operation  if  one  of  the  following  conditions  is  satisfied. 

a)  A  is  a  legal  primitive  operation  by  which  we  mean  that  A  calls  for 
the  application  of  an  action  a  to  an  object  p,  such  that  the  access-right 
(a,p)  exists  in  the  environment. 

b)  A  is  reducible  (equivalent)  to  a  sequence  of  legal  primitive  operations, 
to  be  called  the  components  of  A. 

The  difficulty  here  is  that  one  may  want  to  allow  a  user  to  perform  a  com¬ 
posite  operation  without  authorizing  him  to  perform  any  of  its  components.  An 
example  may  clarify  this  point. 

Let  b,  b',  c,  c'  be  objects  in  a  data  base,  and  let  U  be  a  user. 

Suppose  that  U  is  allowed  to  read  these  four  objects.  In  addition,  he  is  al¬ 
lowed  to  exchange  b  with  b',  and  c  with  c',  but  he  cannot  change  these 
objects  in  any  other  way.  Suppose  that  there  is  a  procedure  EXCH  in  the  data 
base  which  exchanges  any  pair  of  objects  specified  as  its  arguments.  U  should 
be  allowed  to  call  EXCH(b.b')  and  EXCH(c,c'),  but  these  operations  are  not  reduci 
ble  to  legal  primitive  components  since  U  is  not  allowed  to  write  into  the 
objects  b,  b',  c,  c'.  Therefore,  these  operations  must  be  directly  specified 
as  legal  operations  for  U.  But  since  they  are  operations  on  pairs  of  objects , 
there  is  no  way  to  specify  them  by  means  of  Jones'  envi ronment -model .  The  most 
one  can  do  in  this  model  is  to  allow  U  to  apply  the  procedure  EXCH  to  any 
of  the  objects  b,  b' ,  c,  c'.  But  this  would  allow  U  too  much,  for  example, 
to  exchange  b  with  c. 
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In  other  words,  the  problem  with  the  matrix  and  the  environment  models 

is  that  one  does  not  just  access  objects  as  is  assumed  by  these  models;  one 
on  the  data  base 

performs  operations/.  Such  an  operation  can  be  formally  described  as  a  proce¬ 
dure  qQ,  being  applied  to  a  set  of  arguments  q^  ...  q^;  where  the  procedure, 
as  well  as  its  arguments,  may  be  objects  of  the  data  base.  Therefore,  it  is 
not  a  matter  of  the  user  having  a  particular  access  to  an  object,  but  of  him 
being  able  to  perform  an  operation  in  which  several  objects  of  the  data-base 
participate.  To  specify  that  such  an  operation  is  permitted,  we  should  use 
something  like  the  tuple  (q^j,  q^^  ..  q^) ,  rather  than  Jones'  pair  (a,p). 

In  the  case  of  operating  systems,  one  does  not  usually  deal  with 
composite  operations , therefore ,  the  "access -matrix"  model  may  be  satisfactory. 

In  the  case  of  data-bases,  on  the  other  hand,  composite  operations  become 
very  important  so  that  a  more  general  technique  for  the  representation  of 
security  states  is  needed. 

2.2  On  the  Enforcement  of  Security  States 

In  most  papers  on  security  of  data  bases  it  is  assumed,  sometimes  implicitly, 
that  data  bases  can  be  protected  by  means  of  access-control  [Bro.71,  Owe. 71]. 
Indeed  the  term  "access-control"  is  frequently  used  as  a  synonym  for  "protection." 
By  "access-control"  one  usually  means  a  mechanism  which  controls  the  flow  of 
information  into  the  data  base  and  out.  This  mechanism  is  not  supposed  to  have 
any  control  over  the  user's  program  ,  to  be  denoted  by  which  manipulates 
this  information  and  generates  the  various  storage  and  retrieval  requests.  This 
localization  of  the  protection  of  the  protection  mechanism  is  very  convenient. 
Unfortunately,  the  access-control  mechanism  does  not  always  work  well,  as  we  will 
see  now  by  an  example. 
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Consider  a  data  base  in  which  there  is  a  set  A  of  objects,  and  a  func¬ 
tion  F  defined  over  the  members  of  A.  Consider  a  user  U  whose  interaction 
with  the  data  base  has  to  be  restricted  by  the  following  two  rules: 

Rule  1 :  Only  a  subset  A1  c  A  is  accessible  to  U. 

Rule  2:  V  is  allowed  to  apply  F  only  to  members  a'  of  A’ . 

Rule  1  can  be  easily  enforced;  by  means  of  access  control  one  can  simply  filter 
out  every  object  which  does  not  belong  to  A'.  Rule  2  may  seem  to  be  auto¬ 
matically  satisfied;  since,  by  rule  1,  U  does  not  have  an  access  to  objects  of 

A  which  do  not  belong  to  A'.  Unfortunately,  there  is  nothing  to  prevent  the 
user's  program  ir  from  getting  a  copy  of  a  member  of  A  from  an  outside 
source,  or  from  making  up  one  by  itself. 

Thus,  rule  2  is  not  automatically  satisfied  and  must  be  enforced  explicitly. 
One  may  try  to  do  this  by  checking  the  argument  of  F  for  membership  in  A' 
every  time  that  F  is  invoked.  This  may  be  involved  with  a  lot  of  computation 
and  data  base  search  which  is,  in  a  sense,  a  duplication  of  effort.  Moreover, 
one  might  not  be  able  to  perform  such  checking  at  all.  To  see  that,  let  us 
change  our  example  slightly.  Instead  of  rule  2  consider: 

Rule  2':  tt  is  allowed  to  apply  f  only  to  elements  retrieved  by 
tt  from  A*. 

Now,  given  an  invocation  F(a')  of  F,  it  is  not  enough  to  check  if  a'eA', 
because  of  the  following  reasons:  First,  it  may  be  that  a'eA',  but  the  user 
U  did  not  receive  it  legally  from  the  data  base.  Secondly,  it  may  be  that 
when  F(a')  is  invoked,  a'  is  not  a  member  of  A',  but  it  was  a  member  of 
A'  when  U  got  it  from  the  data  base,  Finally,  the  set  A'  may  simply  be 
defined  as  the  set  of  all  objects  which  U  retrieved  from  A,  so  that  there 
is  no  "objective"  criterion  by  which  one  can  determine  if  a'eA'.  One  can  get 


around  these  difficulties  by  maintaining  a  record  of  all  members  of  A'  which 
have  been  retrieved  by  it,  however,  this  may  be  extremely  wasteful  and  can  be 
considered  as  an  entirely  unrealistic  solution. 

It  should  be  pointed  out  that  rules  such  as  1  and  2  (or  2')  appear 
frequently  in  practice.  Suppose,  for  example,  that  A  is  a  set  of  names  of 
patients  in  a  medical  data  base.  Let  the  user  U  be  a  doctor,  and  let  A'  c  a 
be  the  set  of  names  of  the  patients  of  U.  Let  F(a)  be  a  function  which 
returns  some  personal  information  about  the  patient  a.  In  this  case  rules  1 
and  2  simply  mean  that  the  doctor  is  allowed  to  get  personal  information 
about  his  own  patients  only,  which  is  a  very  reasonable  restriction.  As  an 
example  of  rule  2',  consider  the  same  doctor  who  wants  to  transfer  a  patient 
of  his  own  to  another  doctor,  to  be  done  by  the  function  F.  He  does  it  as 
follows:  A  patient  name  a'eA'  is  retrieved,  and  deleted  from  A'.  When 
F(a')  is  invoked,  assigning  a'  to  another  doctor,  it  is  already  too  late 
to  verify  that  a'  is  a  member  of  A';  it  is  not  any  more. 

Thus,  it  was  shown  t>at  the  enforcement  of  some  common  restrictions  by 
means  of  access -control  can  only  be  achieved  at  the  price  of  gross  inefficiency 
But  the  example  above  also  suggests  a  solution  to  this  problem.  If  one  can 
guarantee  that  only  objects  retrieved  from  A'  can  be  used  by  tt  as 
parameters  of  F,  then  rule  2  (or  2’)  is  automatically  satisfied.  This, 
however,  requires  that  it  should  be  restricted  in  certain  ways.  The  form  of 
such  a  restriction  will  be  discussed  next. 


3.  A  Basic  Model  for  the  Interaction  of  Users  with  the  Data  Base. 

It  has  been  shown  in  the  last  section  that  access-control  alone  is  not  a 
satisfactory  tool  for  protection  of  data  base  .  It  has  also  been  suggested 
that  one  might  get  better  results  by  exerting  some  control  over  users'  programs 
which  interact  with  the  data  base.  In  this  section  we  will  consider  a  model 
for  the  user  data  base  interaction  which  admits  such  a  control.  (The  model 
to  be  discussed  here  is  intentionally  simplified.  Some  generalizations  of  it 
will  be  discussed  in  section  4.) 

The  main  participants  in  the  user  data-base  interaction  are  the  data-base 
D,  and  the  user  U  who  is  using  a  program  it.  This  interaction  is  supervised 
by  a  mechanism  (or  data  structure)  which  we  will  call  schema ^ ^ ,  to  be  denoted 
by  S.  The  schema  is  supposed  to  contain  the  security -state  for  a  given  set 
of  users,  namely,  the  definition  of  what  these  users  can  and  cannot  do.  For 
a  program  ir,  written  by  a  user  U,  to  operate,  it  must  be  "connected"  to  one 
of  the  schemas  in  D.  This  connection  mechanism  will  not  be  specified  here, 
but  the  following  is  assumed  about  it:  Every  schema  S  is  connectable  to 
programs  which  "belong"  to  a  specific  set  of  users  to  be  called  the  patrons 
of  the  schema  S,  provided  that  they  are  written  in  a  given  programming  language 
L(S)  (or  simply,  L) .  (For  example,  a  certain  schema  in  a  medical  data  base 
may  be  connectable  only  to  COBOL  programs  written  by  doctors.)  It  is  also 
assumed  that  once  such  a  connection  is  done,  the  correct  identity,  U,  of  the 
user  is  known  to  the  schema.  (This,  of  course,  is  a  very  strong  assumption 
which  is  very  hard  to  satisfy.) 

(1)  The  concept  of  schema  as  an  interface  between  user's  programs  and  the 
data  base  is  a  well-known  and  extremely  important  part  of  the  data  base 
architecture.  (However,  it  is  typically  called  sub-schema.)  It  was 
initially  introduced  in  order  to  help  reducing  the  dependency  of  n  on 
the  storage  structure  of  the  data  base  [Dbtg.72],  but  its  potential  role 
in  maintaining  security  (usually  by  access-control)  is  also  well  recognized. 
It  is  the  security  role  of  the  schema  which  would  interest  us  here. 
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The  program  it  which  is  connected  to  the  schema  S  would  be  denoted 
by  ir/S.^  The  way  in  which  tt/S  is  controlled  by  S  is  discussed  next. 

3. 1  A  Model  for  Users'  Programs 

The  program  ir/S  operates  within  an  environment  defined  jointly  by  the 
schema  S  and  by  the  programming  language  L  in  which  it  is  written.  This 
environment  consists  essentially  of  a  set  Q  of  objects  available  to  it,  and 
a  set  R  of  rules  which  specify  the  operations  that  it  can  apply  to  objects 
in  Q. 

The  set  Q  is  a  union  of  the  following  three  disjoint  sets: 

a)  The  set  QL  of  primitive  objects.  These  are  the  primitives  of  the 
programming  language  L.  For  example,  a  primitive  operator  such  as  "+",  or  a 
constant  such  as  "179  ", 

b)  The  set  Q<,  of  permanent  objects.  These  are  objects  which  belong  to 
the  the  data  base,  and  which  are  made  available  to  ir/S  by  the  schema  S.  Such 
objects  may  be,  for  example,  files  and  procedures  which  operate  on  them.  They 
are  '|>ermanent"  only  in  the  sense  that  their  existence  does  not  depend  on  the 
existence  of  a  program  it  which  interacts  with  them. 

c)  The  set  Q^,  of  transient  objects,  objects  which  are  generated  by  n 
itself.  Such  an  object  exists  only  in  the  context  of  the  program  which  generated 
it,  and  it  disappears  with  the  program. 

As  to  the  structure  of  the  objects  we  will  only  say  this:  Every  object 
qeQ  is  a  pair 

q  =  (brand,  value) 


(1)  We  will  occasionally  write  it  instead  of  n/S 
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where  the  brand  is  a  symbol  which  is  a  member  of  a  set  B,  to  be  introduced  below. 
The  role  of  the  brands  in  our  model  which  will  be  explained  in  detail  later 
would  be  similar,  but  not  identical,  to  the  role  of  types  in  most  programming 
languages.  The  rest  of  the  object,  which  is  called  its  value  , can  be  any  data 
structure,  e.g.,  a  number,  a  file  or  a  procedure. 

The  set  of  brands  B  is  a  set  of  symbols.  It  is  a  union  of  two  sets, 

B  =  B^  v  Bg,  as  we  will  yet  see  B^  would  be  part  of  the  specification  of  the 

language  L,  and  Bg  would  be  part  of  the  schema  S. 

The  following  can  be  said  about  the  brands  of  the  three  classes  of  objects 
introduced  below: 

a)  The  brands  of  objects  qeQ^  will  be  members  of  B^. 

b)  The  brands  of  the  objects  of  Qg  would  be  the  names  of  these  objects 

themselves.  (This  is  a  rather  formalistic  point;  these  brands  will  not  be 
actually  used,  and  we  therefore  do  not  include  the  names  of  the  objects  of  Qg 
in  the  set  of  brands) . 

c)  The  objects  in  Q^,  may  have  any  brand  from  B,  according  to  the  rules 
which  will  be  introduced  later. 

Some  conventions  about  brands  are  in  order: 

a)  To  distinguish  between  brands  and  other  symbols  which  will  appear  in 
our  discussion,  we  will  denote  the  former  by  a  bar,  e.g.,  F  (generic  brands 
will  be  denoted  without  a  bar). 

b)  The  set  B^  would  always  contain  the  distinguished  brand  <j>  ,  to  be 
called  the  "empty  brand,"  its  meaning  and  use  will  be  described  later. 

The  process  induced  by  tt/S  can  be  described  as  a  sequence  of  operations 
of  the  following  form! 


<1  <a,:  %(<*!  •••  qk)  (k  *  0) 


(3.1) 


where  q^eQ  is  an  operator  (procedure),  and  q^eQ  (for  i  £  1)  are  assumed  to 
be  the  operands  (parameters).  Such  an  operation  may  have  two  effects.  First, 
it  generates  a  new  (possibly  null)  transient  object,  denoted  here  by  q,  to 
be  called  the  product  of  the  operation.  Secondly,  it  may  have  "side-effects" 
on  the  data  base  D. 

Note  that  the  concepts  of  variable  and  assignment ^  are  avoided  in  this 
'abstraction.  Transient  objects  can  be  generated  and  used,  but  they  cannot  be 
changed.  The  questions  of  where  is  a  generated  object  stored,  and  how  is  it 
accessed  are  ignored  at  this  point. 

The  specific  operations  which  ir/S  is  allowed  to  perform  are  specified  by 
a  finite  set  of  rules  R,  to  be  called  application-rules.  The  rules  reR  have 
the  following  general  structure: 

r  =  P  ♦  (P0,  P1  .. .  Pk)  (3.2) 

where,  pcB,  p.  e  B  v  Q  v  Q  for  0  S  i  £  k. 

The  right  hand  side  of  a  rule  is  called  right,  and  will  be  denoted  by  p.  It 

is  required  that  every  right  appears  at  most  once  in  R. 

Let  us  define  next  the  set  of  all  operations  which  are  legalized  by  a 
rule  r--to  be  denoted  by  op(r) --as  follows: 

Definition:  An  operation  •••  xn)  is  *n  °P(r)  f°r  T  =  P  Pq^i  ••• 

if  the  following  conditions  are  satisfied. 

a)  k  =  n 

b)  For  0  s  i  sk,  if  p.  e  QL  v  Qg  then  x^,  =>  p^ 

c)  For  0  <  i  s  k,  if  p.  e  B,  then  X^  may  be  any  object  whose 

brand  is  p^. 

It  is  clear  from  this  definition,  and  from  the  definition  of  R  that  every 


(1)  The  "<=*"  sign  in  (3.1)  is  not  an  "assignment  symbol,"  it  is  meant  only 
to  show  that  the  operation  generates  an  object  q. 
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operation  belongs  to  at  most  one  set  op(r).  Namely,  there  is  at  most  one  rule 
which  legalizes  any  given  operation. 

The  existence  of  a  rule  reR  is  supposed  to  have  the  following  affect  on 
every  ir/S.  First,  it  gives  to  v/S  the  right  to  perform  all  operations  in 
op(r).  Secondly,  if  any  one  of  these  operations  is  performed,  and  if  it  gen¬ 
erates  a  product,  this  product  would  be  branded  by  p  (the  left  hand  side  of  r) 
If,  in  particular,  p  =  ^  (the  special  null  brand),  then  any  product  that  the 
operation  may  have  will  be  "annihilated;"  namely,  no  transient  object  will  be 
generated.  (Instead  of  the  rule  (pQ  ...  p^) ,  we  will  usually  write  only 
"(Pq  ...  p^)".)Actual  techniques  for  enforcing  these  rules  will  be  discussed 
later;  for  the  time  being  we  will  just  assume  that  the  rules  in  R  are  observed 

Note  that  our  rules  have  nothing  to  say  about  the  operations  themselves; 
they  only  specify  which  operations  can  be  applied  to  which  operands,  thus,  the 
name  "application  rules."  The  meaning  of  the  operations  themselves  is  supposed 
to  be  imbedded  in  their  value  parts. 

The  set  R  of  rules  is  a  union  of  two  sets,  R^  and  Rg,  to  be  defined 
as  part  of  L  and  S  respectively.  These  two  sets  will  be  described  below 
in  some  detail. 

3.2  The  specification  of  L  and  S 

As  was  pointed  out  before,  the  environment  of  tt/S  is  defined  jointly 
by  the  programming  language  L,  and  the  schema  S.  But  the  two  do  not  play 
symmetric  rules  in  this  definition.  The  schema  will  be  defined  in  terms  of  a 
particular  language  L,  while  L  must  be  completely  independent  of  any  schema, 
because  several  different  schema's  may  be  using  the  same  L.  We  will  now 
summarize  the  information  needed  for  the  specification  of  both  L  and  S. 
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The  language  L  can  be  characterized  within  our  level  of  abstraction  by 
the  sets  QL,  B^, 

-  is  the  set  of  primitive  objects  of  L.  This  includes  both  operators 
and  structures.  Specific  examples  of  such  primitives  will  not  be  given. 
Here  we  will  only  introduce  an  operator  which  should  be  present  in  every 
Ql.  It  is  the  identity  operator  I  which, when  applied  to  any  object, 

generates  a  copy  of  its  value  part.  If  the  rule  p  •*-  (I,  pp  exists  in 
R,  it  means  that  every  object  branded  by  p^^  can  be  copied,  and  the  copy 
is  branded  by  p^.  For  brevity  we  will  denote  the  rule  p2  «■  (I,  Pj)  by 
P2  *  CPj) • 

-  is  a  set  of  brands.  To  distinguish  between  these  brands  and  those  in  B<,, 
we  will  add  the  prefix  X  to  every  symbol  in  B^.  In  a  typical  case, 
the  brands  in  would  closely  correspond  to  the  types  of  normal  pro¬ 
gramming  languages.  We  may,  for  example,  have  the  following  brands  in 
B^:  X.I  --  to  brand  integer  objects,  X.R  for  real,  X.S  for  string 
objects,  etc. 

RL  -  is  a  set  of  primitive  application  rules  of  the  language  L.  They  have 
the  same  general  form  of  rules  in  R: 

P  (P0  *  •  •  Pk). 

but  the  range  of  the  various  arguments  is  more  restricted: 

peB  ,  p.  e  B  v  Q  for  i  H 
L  ILL 

As  an  example,  we  may  have  the  following  rules  in  R  : 

L 

xT^  (♦,  xTT,  ITT) 

X.R-*-  (♦,  X.R,  X.R) 

x.r  *■  (+,  x.I,  XTR) , 
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which  means  that  the  integer  to  integer  addition  gives  an  integer  result, 

but  the  addition  of  real  to  real ,  or  real  to  integer  gives  a  real  result. 

It  should  be  pointed  out  that  we  do  not  really  expect  R.  or  Q.  to  be 
explicitly  defined  in  this  way.  But  the  brands  will  be  used  in  the  defi¬ 

nition  of  the  schema  and  must  be  defined  explicitly. 

The  schema  S  is  specified  by  means  of  the  sets  Qg,  Bg,  Lg.  As  was 
already  pointed  out,  the  schema  is  defined  in  terms  of  a  given  language  L. 

It  is  connectable  to  programs  written  in  this  language,  which  belong  to  a 
given  set  of  users,  called  the  patrons  of  S. 

The  set  of  permanent-objects  --  Qg  are  those  objects  of  the  data  base 
which  should  be  accessible  to  the  patrons  of  S.  Two  comments  are  in  order  here. 

a)  The  designer  of  the  schema  may  decide  that  a  given  object  P  should 
not  be  accessible  to  the  users  in  its  raw  form.  He  may  then  write  a  procedure 
P'  which  has  an  access  to  P,  but  which  manipulates  P  in  a  certain  desired 
way.  P' ,  rather  than  P,  is  then  listed  in  Qg,  and  the  users  can  access  P 
only  in  a  controlled  way,  via  P'.  This  is  an  example  of  access -control ,  and 

it  is  outside  the  scope  of  this  paper  as  is  the  general  subject  of  construction 
and  manipulation  of  the  schema. 

b)  Our  second  comment  is  that  the  binding-time  of  the  symbols  in  Qg  does 
not  have  to  be  the  definition-time  of  S.  It  can  be  the  connection-time  with 

a  particular  program  tt  owned  by  user  U.  Thus,  the  interpretation  of  a;,y 
sumbol  in  Qg  may  well  depend  upon  U.  For  example,  consider  a  schema  in  a 
medical  data  base  whose  patrons  are  doctors.  We  may  have  a  symbol  PAT  in 
Qg  of  this  schema  which  would  give  to  each  doctor  the  set  of  his  own  patients. 
This  is  a  very  powerful  capability  of  the  schema. 

The  objects  in  Qg  cannot  be  manipulated  freely  by  -rr/S ;  the  use  of 
these  objects  is  controlled  by  the  rules  in  Rg.  The  effect  of  these  rules  on 
tt/S  is  best  seen  by  means  of  examples  which  will  be  given  next. 


The  examples  in  this  section  have  two  objectives:  To  illustrate  the 
concepts  introduced  above,  and  to  show  their  relevance  for  protection. 

Example  1:  Consider  a  binary  tree  T  stored  in  a  bata  base.  Suppose 
that  there  are  four  functions  defined  on  the  nodes  neT:  LSON(n)  and  RSON(n) 
which  return  pointers  to  the  left  and  right  "sons"  of  node  n;  and  KEY(n) 
and  TEXT(n)  which  return  the  "data"  stored  in  node  n.  This  data  is  given  in 
integer  and  string  formats,  respectively.  (What  we  call  "function"  is  usually 
called  an  "attribute"  of  a  node.) 

For  every  node  neT,  let  us  define  Tree(n)  to  be  the  subtree  of  T  whose 
root  is  n.  The  following  schema  gives  to  every  tt/S  certain  access  rights  to 
all  the  nodes  in  Tree(N)  for  a  given  node  N. 

The  schema  S  is  defined  by  means  of  the  sets  Qg,  Bg,  Rg: 

Qs  =  {N,LSON,RSON, KEY, TEXT, STORE) 

Bs  =  (  n  } 


{  rl  : 

n  (N) 

r2  : 

n  «-  (LSON,n) 

r3  : 

n  (RSON,n) 

r4  : 

A.  I  «-  (KEY ,n) 

r5  : 

ITS-  «-  (TEXT,n) 

r6  : 

(STORE, TEXT,n, ITT)} 

Let  us  see  what  can  tt/S  possibly  do. 

By  rules  r^,  r^ ,  r^,  he  can  get  to  the  pointers  of  every  node  in  Tree(N). 
All  such  nodes  are  branded  by  n.  Moreover,  only  nodes  of  Tree(N)  can  be  iT- 
branded  because  there  is  no  other  rule  whose  product  has  n  as  its  brand.  Now, 
rule  r4  allows  tt/S  to  apply  the  function  KEY  to  any  n-branded  object; 
that  is,  to  any  node  in  Tree(N) ,  and  only  to  these.  Note  in  particular,  that 
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it  will  not  help  the  user  to  get  a  pointer  to  a  node  in  the  tree  T  from 
some  outside  source;  such  a  pointer  will  not  be  n-branded.  Note  also  that  to 
get  this  security  there  is  no  need  to  check  at  run  time  if  a  given  argument  of 

KEY  is  in  Tree(N).  It  is  enough  that  the  rules  in  Rg  are  satisfied. 

Any  object  generated  by  the  function  KEY  is  branded  by  X.I  (rule  r4) . 
Since  X. I  belongs  to  B. ,  such  an  object  is  under  the  jurisdiction  of  the  opera- 
tion  ruleS'-R^  of  the  language  L.  Namely,  ir/S  can  do  with  it  whatever  the 
language  L  is  able  to  do  with  1 .  I  branded  objects.  (In  this  particular 
case,  X.I  is  assumed  to  be  the  brand  of  integer  objects  (numbers),)  In  such 
a  case  we  will  say  that  an  object  is  released  to  the  user  because  it  is  not 
controlled  by  the  schema  anymore.  All  objects  whose  brands  are  from  will 

accordingly  be  called  free  objects. 

Rule  r5  is  similar  to  r4;  it  allows  ir/S  to  get  the  TEXT  of  nodes  in 

Tree(N).  The  result  is  again  released  to  the  user  in  the  form  of  string 

objects  (branded  by  X.S) .  Finally,  r6  is  a  right  to  invoke  the  procedure 
STORE (TEXT ,  n ,  X .  S )  which  is  supposed  to  store  a  new  value  in  TEXT(n) ;  this  value 
must  be  a  free  string  object. 

Let  us  point  out  that,  as  it  was  explained  in  section  3.2,  the  "b.nding- 
time"  of  the  various  symbols  in  S  is  the  time  of  "connection”  between  it 
and  S.  This  allows  N  to  depend  on  the  user  U.  Therefore,  the  same  schema 
may  allow  various  users  to  get  to  different  subtrees  of  T. 

Example  2:  Consider  a  medical  data  base  in  which  there  is  a  set  of  pa¬ 
tients  PAT.  Each  patient  pePAT  has  two  attributes,  MEDICAL  and  PERSONAL, which 
hold  the  medical  and  personal  information  about  the  patient  in  string  format. 
There  are  also  other  functions  in  the  data  base  which  are  relevant  to  us;  they 
will  be  introduced  later. 
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The  patrons  of  the  following  schema  are  the  doctors  in  the  hospital. 

Each  doctor  U  is  supposed  to  have  access  to  two  sets  of  patients:  MY-PAT 
is  the  set  of  all  patients  treated  by  doctor  1)  himself,  and  DEP-PAT  are  all 
the  patients  in  the  department  in  which  U  works.  U  would  have  different 
access  rights  to  these  two  sets,  as  we  will  see  below. 

The  schema  is  defined  by: 

Qs  =  {MY-PAT, DEP-PAT, NEXT, MEDICAL, PERSONAL, STAT1 ,STAT2 ,STAT3 , DELETE, ADD} 

BS  =  <V  V 


«  {  rl  : 

ql  * 

(NEXT, MY-PAT) 

r2  : 

x.s 

G? 

r3  : 

<2  *" 

(NEXT, DEP-PAT) 

r4  : 

x.s  •+■ 

(qj) 

r5  : 

x.s 

(MEDICAL, qp 

r6  : 

O  «- 

(PERSONAL,^) 

r7  : 

«3  * 

(MEDICAL, qj) 

r8  : 

xTT  ♦ 

({STAT1 ,STAT2 ,STAT3) ,qj) 

r9  : 

(DELETE, MY-PAT, q^) 

rlO: 

( ADD, MY- PAT, q^) 

For  simplicity,  we  assume  that  the  sets  MY-PAT  and  DEP-PAT  are  ordered  sets 
of  names  of  patients.  The  function  NEXT  returns  on  each  call  the  next 
patient  name.  The  doctor  U  is  allowed  to  get  the  names  of  patients  in  these 
two  sets  (by  rules  rl,  r3) ,  and  these  names  are  released  as  free  string  objects 
(rules  r2,  r4) .  But  there  are  some  privileged  operators  which  can  be  applied 
only  to  names  retrieved  from  MY-PAT  and  DEP-PAT. 

By  rules  r5  and  r6  the  doctor  can  get  the  medical  and  personal  infor¬ 
mation  about  his  own  patients.  Moreover,  this  information  is  released  to  him. 
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His  access  to  the  other  patients  is  more  restricted.  He  cannot  get  any 
personal  information  about  these.  He  can  get  MEDICAL  data  about  them,  but 
this  data  is  not  released;  it  is  branded  by  qj  (rule  r7) .  The  doctor  can¬ 
not,  for  example,  print  this  information.  He  can  only  use  it  as  a  parameter 
to  the  three  functions  STAT1,  STAT2,  STAT3  (Using  an  obvious  convention, 
rule  r8  is  equivalent  to  three  rules,  one  of  them,  for  example,  is 
X.I  (STATl.q^).  These  three  functions  are  assumed  to  be  statistical 
functions  built  into  the  data  base.  The  idea  is  that  the  medical  data  of 
patients  not  treated  by  the  doctor  can  be  retrieved  by  him ;  but  he  can  only 
use  them  for  some  well-defined  statistical  purposes.  Namely,  they  can  only  be 
fed  to  the  three  statistical  routines. 

Finally,  the  doctor  can  delete  a  patient  from  the  set  MY-PAT  (by  r9) , 
or  add  a  patient  of  the  department  to  MY-PAT  (by  rlO) . 

3.4  Enforcement  of  the  Application-Rules 

Until  now  it  was  assumed  that  the  application-rules  are  honored  by  the 
programs  ir/S;  we  will  now  consider  techniques  for  enforcing  them. 

The  most  obvious  way  for  enforcing  the  rules  in  R  is  to  do  it  at 
"run-time":  When  an  operation  (q1  ...  q^)  is  about  to  be  executed,  one 
searches  in  R  for  a  rule  r  which  gives  the  right  to  execute  this  operation. 
Once  the  operation  is  carried  out,  and  if  it  generates  a  product,  this  product 
is  branded  by  the  left  hand  side  of  the  rule  r. 

Because  of  obvious  reasons  of  efficiency,  run-time  checking  should  be  avoided 
whenever  possible.  For  this  purpose  in  mind,  let  us  introduce  into  our  model 
the  concepts  of  variable  and  aeeignment  operator  which  were  avoided  until  now. 
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Definition :  A  variable  is  an  object  which  has  another  object  as  its 

value.  Moreover,  the  value  part  of  a  variable  can  be  changed.  The  only  way 
to  change  the  value  of  a  variable  is  by  means  of  the  operator  to  be  called 

assignment  operator 3  as  follows:  If  v  is  a  variable  and  q  is  a  non-variable 
object,  then  the  operation  :  =  (v,q),  which  is  conventionally  denoted  by  v:=q, 
copies  object  q  into  the  value  part  of  v.  (For  simplicity  we  assume  that 
the  product  of  the  assignment  operator  is  null.) 

To  fully  incorporate  variables  into  our  model,  we  introduce  the  following 
convention.  Whenever  a  variable  appears  in  an  operation,  other  than  as  the 
first  argument  of  the  assignment  operator,  the  effect  is  as  if  the  value  part 
of  the  variable  appears  in  the  same  place.  This,  of  course,  is  the  normal 
treatment  of  variables. 

Now,  it  makes  sense  to  talk  about  the  scope  of  a  particular  variable  which 
is  defined  here  to  be  the  set  of  objects  which  can  legally  be  assigned  to  it. 

The  scope  of  a  variable,  being  so  defined,  obviously  depends  upon  the  set  of 
rules  R.  For  illustration,  consider  the  following  example. 

Let  a  language  L  be  defined  by: 

Ql  =  {DECLARE, INTEGER, :=,...} 
bl  =  (I,  TV,  . . . } 

Rl  *  {rl  :  TV  (DECLARE , INTEGER) 

r2  ;  ( :  =  »TV,T) 

} 

By  rule  rl,  the  operation  DECLARE (INTEGER)  creates  an  object  branded  by 
IV.  Suppose  that  this  is  the  only  operation  which  generates  TV-branded  objects. 
By  rule  r2,  IV-branded  objects  are  variables.  If  we  also  assume  that  r2  is  the 
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only  rule  in  R  in  which  the  symbols  and  "IV"  appear  as  the  first  two 

parameters,  then  it  is  clear  that  only  integer  objects  can  be  assigned  to  TV- 
branded  objects.  These  objects  are,  therefore,  what  is  normally  called  "integer 
variables." 

In  general,  for  every  brand  fj,  it  is  possible  to  generate  variables  whose 
scope  is  the  set  of  all  objects  branded  by  8.  We  will  say  that  the  scope 
of  such  a  variable  is_  8. 

Now,  if  the  scope  of  every  variable  used  in  a  program  tt  is  some  8eB, 
then  we  do  not  need  explicit  brands  to  be  stored  in  our  objects.  Moreover,  if 
the  names  of  all  variables  in  a  program  are  declared  together  with  their  scope, 
and  if  their  names  are  used  explicitly  in  the  program,  then  it  is  clear  that 
the  application  rules  can  be  enforced  at  compile -time. 

3.5  On  the  Concept  of  "Type" 

The  reader  may  be  wondering  why  did  we  choose  to  use  the  names  brand  and 
scope  for  what  may  seem  to  be  simply  the  standard  concept  of  type.  We  will  make 
a  small  digression  from  our  main  subject  to  clarify  this  point. 

First,  it  should  be  pointed  out  that  there  is  actually  no  standard  meaning 
to  the  term  '  ype"  in  programming.  This  concept  is  currently  in  a  process  of 
evolution,  and  different  people  may  have  different  things  in  mind  when  they  use 
the  term  "type."  This  is  one  good  reason  for  avoiding  the  use  of  this  term. 

But  there  is  also  another,  more  serious  reason:  The  term  "type"  is  frequently 
used  for  two  fundamentally  different  concepts  at  the  same  time. 

First,  types  are  used  as  descriptors  of  objects.  For  example,  the  state¬ 
ment  "the  value  of  a  function  is  of  type  integer"  is  a  statement  about  the 
objects  generated  by  the  function.  (In  this  paper  we  used  brands  for  this 
purpose.)  However,  the  term  type  is  also  used  in  an  entirely  different  way: 
the  statement  "the  type  of  a  variable  is  INTEGER"  is  a  statement  about  the 
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saope  of  the  variable.  In  a  language  like  FORTRAN  or  ALGOL  It  may  not  be 
clear  that  there  are  two  different  concepts  here,  because  in  these  languages 
the  scope  of  a  variable  must  coincide  with  a  set  of  all  object  of  a  given 
type  (or:  with  a  given  brand),  e.g.,  integer  variable,  real  variable,  etc. 

The  difference  between  the  scope  of  a  variable  and  the  brand  of  an  object 
becomes  important  when  the  scope  of  a  variable  may  be  the  set  {1  ...  10}  for 
example.  Thus,  there  should  be  no  correspondence  between  the  first  interpre¬ 
tation  of  the  type  and  the  second  interpretation  -  as  a  scope. 

The  failure  to  make  a  clear  distinction  between  these  two  concepts  by 
using  the  same  term  like  "type  or  "mode"  for  both  of  them  may  cause  con¬ 
siderable  confusion.  Like  the  "mode-UNION"  confusion  in  ALGOL/68. 

It  should  be  pointed  out  that  if  one  wishes  to  use  an  axiomatic  approach 
to  the  concept  of  type,  then  the  scope  of  a  variable  is  not  a  new  concept  at 
all.  It  is  a  property  of  a  variable -object  which  is  derivable  from  the  under¬ 
lying  application-rules  of  the  language,  similarly  to  what  was  done  in  the 
last  section. 
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Extension  of  the  Basic  Model 


In  this  section  we  will  see  that  our  model  is  too  primitive  to  be  practical 
Several  extensions  to  it  will  be  considered  but  will  not  be  discussed  in 
depth. 


4. 1  Value-Dependent  Rules 

The  most  obvious  limitation  of  our  rules  is  that  they  are  defined  in  terms 
of  the  names  in  Q,  and  the  brands  in  B  only;  and  they  are  totally  invariant 
of  the  value  parts  of  the  objects  involved.  For  example,  rule  r5  in  example  2 
of  section  3.3  allows  tt/S  to  get  the  medical  information  about  any  patient 
whose  identifier  is  branded  by  q^.  However,  one  might  want  to  condition  the 
application  of  this  rule  on  some  property  of  the  patient.  For  that,  let  us 


generalize  the  rules  defined  in  (3.2)  to  the  form: 

r'  :  P  «-  (p  ...  Pk)/C(<l0  ••• 


(4.1) 


The  meaning  of  this  rule  is  the  following:  suppose  that  q  <—  qg(q^...qk)  is  an 
operation  which  is  about  to  be  performed  by  tt/S,  and  that  this  operation  belongs 
to  op(r)  for  the  rule  r  :  p  (p  . ..pk).  tt/S  will  be  permitted  to  carry  out  the 
operation  only  if  C(qQ....  qk)  is  satisfied  (C  is  assumed  to  be  a  predicate). 

Another  restriction  that  one  would  like  to  lift  from  our  rules  is  the  fact 
that  all  the  operations,  op(r) ,  legalized  by  the  rule  r,  generate  objects  with 
the  same  brand.  A  higher  "resolution  power"  of  A  brands  can  be  achieved  by 
the  following  form  of  rules: 

r”  :  (p1/c1,p2/c2,  ...  pn/cn)  -  (p0  ...  pk)/c(q0  •••  qk) •  (4.2) 

The  right  hand  side  of  r"  is  identical  to  r'.  The  p1  in  the  left  side  of 
r"  are  brands,  and  c1  are  predicates  defined  over  q^Q  •  •  •  qk  of  the  opera¬ 
tion  in  hand.  The  left  hand  side  of  r"  determines  the  brand  of  the  product 
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of  the  operation  Legalized  by  it,  as  follows:  The  predicates  c1  are  computed 
one  by  one  beginning  with  c^.  If  c1  is  the  first  to  be  satisfied,  the 
brand  of  the  product  would  be  p1.  If  none  is  satisfied,  then  the  brand  is  <j>. 

4. 2  Variable  Brands 

The  brands  defined  in  section  3  were  a  finite  set  of  symbols.  These  sym¬ 
bols  appeared  explicitly  in  the  application  rules.  There  seem  to  be  good  reasons, 
however,  to  use  more  complex  structures  as  brands,  and  to  have  variable  brands 
appear  in  our  rules.  The  following  example  indicates  such  a  need: 

Consider  a  medical  data  base  and  a  schema  S  which  is  supposed  to  be 
used  by  nurses  in  the  hospital.  The  following  is  a  partial  list  of  the  rules 
in  Rg  given  in  the  form  of  section  3.  We  will  first  explain  these  rules, 
and  then  point  out  to  the  difficulty  that  they  present, 
rl  :  d  *  (NEXT, DOC) 

r2  :  pset  «-  (PAT,  d  ) 

r3  :  p  (NEXT, pset) 

r4  :  pp^  (PERSONAL,  p  ) 

r5  :  (SEND,pp,d) 

DOC  is  a  set  of  names  of  doctors  which  is  accessible  to  a  nurse  U.  Each 
doctor  name  generated  by  NEXT(DOC)  is  branded  by  d  (rule  rl).  The  function 
PAT  applied  to  a  legal  name  of  a  doctor  returns  a  set  of  patients  of  this  doc¬ 
tor,  to  be  branded  by  pset  (r2).  There  may  be  many  such  sets;  U  can  get 
the  names  in  each  of  them  by  the  operator  NEXT;  the  patient  name  so  received 
is  branded  by  p.  By  rule  r5 ,  U  can  get  the  personal  information  of  every 
p-branded  patient. 


Now  suppose  that  the  operation  SEND(text ,doct)  sends  the  information 
text  to  a  file  which  belongs  to  the  doctor  do  at.  We  would  like  to  allow  U 
to  send  personal  information  about  a  patient  to  the  file  of  the  doctor  who 
treats  this  patient,  and  only  to  him.  Rule  r5 ,  however,  does  not  do  that; 
it  allows  U  to  send  such  information  to  any  doctor.  Moreover,  there  does  not 
seem  to  be  any  clear  way  to  impose  such  a  restriction  by  our  form  of  rules. 

To  do  so,  we  will  have  to  generalize  our  brand  concept: 

Suppose  that  every  brand  is  a  pair  31.32  ;  where  31  is  a  symbol,  such 
as  we  had  until  now;  and  32  is  an  arbitrary  integer  number.  Using  such  brands 
we  redefine  our  rules  as  follows: 


rl' 

:  d.i 

<*-  (NEXT, DOC) 

r2 ' 

:  pset.i 

«-  (PAT.dTi) 

43' 

:  pTT 

*■  (NEXT,pset.  i) 

r4' 

:  pp.i 

(PERSONAL,  pTT) 

r5 ' 

(SEND,pp. i ,d. i] 

i  is  assumed  to  be  a  variable  which  may  hold  any  integer.  It  is  assumed  that 

every  activation  of  NEXT(DOC)  which  retrieves  a  doctor's  name,  brands  it  by 

d.i  ,  with  a  different  i  for  every  doctor.  This  i  is  carried  to  the  brands 

of  the  patients  (by  rules  r2',  r3'),  and  their  personal  information  (rule  x 4 1 ) . 

Thus ,  the  brand  of  the  personal  information  of  a  patient  carries  in  it  the 
identification  of  the  doctor  of  that  patient.  It  is  therefore  possible,  by 
rule  r5',  to  allow  U  to  send  such  information  the  right  doctor  only. 

This  example  clearly  suggests  that  variable,  and  non-scaler  brands  may 
be  useful.  A  systematic  model  of  such  brands  is  yet  to  be  worked  out. 
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4.3  Global  Brands 

The  brands t  as  they  were  introduced  in  section  3,  are  strictly  local 
to  the  schema  and  to  the  users'  programs  working  under  it.  An  obvious 
generalization  to  make  is  to  let  objects  in  the  data  base  have  global  brands; 
indeed,  such  a  generalization  is  absolutely  necessary.  The  global  brands  may 
be  used  not  only  by  rules  in  individual  schemas,  they  may  also  be  utilized  in 
the  formulation  of  a  "constitution"  for  the  data  base,  namely,  a  set  of  rules 
with  which  every  schema  must  conform. 
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5.  Conclusion 


Two  aspects  of  security  in  data  bases  were  discussed  in  this  paper:  the 
description  of  the  security  state ,  and  its  enforcement  mechanism.  The  conven¬ 
tional  approach  to  these  two  aspects  has  been  found  to  be  inadequate,  and  a 
new  approach  has  been  proposed.  According  to  the  proposed  approach,  the  user's 
program-it  which  interacts  with  the  data  base  operates  under  the  jurisdication 
of  a  set  of  rules,  collectively  called  schema,  which  in  effect  defines  the 
security  state  of  the  data  base  with  respect  to  a  given  set  uf  users.  The 
function  of  the  schema  is  to  authorize  the  operations  performed  by  it.  In  such 
a  way  it  can  control  the  fate  of  information  originated  by  the  data  base,  or 
otherwise  related  to  it,  even  when  such  information  is  in  the  user's  working 
space.  But  the  schema  has  no  authority  over  information  which  is  not  related 
data  base,  and  over  the  computation  performed  by  it  on  such  information. 

This  paper  is  only  a  first  step  in  a  research  which  should  progress  in 
several  directions,  as  is  briefly  outlined  below: 

a)  The  model  for  user  data  base  interaction  proposed  here  is  a  radical 
change  from  the  conventional  form  of  such  interaction  under  which  users' 
programs  were  completely  free.  Various  pragmatic  aspects  of  our  approach  should 
therefore  be  carefully  assessed.  In  particular,  it  is  not  quite  clear  how 
various  general  purpose  languages  should  be  adapted  for  the  role  designed  for 
them  in  our  model.  (It  should  be  pointed  out  that  the  need  to  change  general 
purpose  languages  in  order  to  adapt  them  for  the  interaction  with  data  bases 

is  not  new  with  us,  see,  for  example,  DBTG  reput  [Dbtg.71]. 

b)  A  convenient  language  for  schema  specification  should  be  developed. 


c)  The  model  proposed  here  is  very  basic.  Some  possible  extensions 
of  it  were  briefly  outlined  in  section  4;  they  should  be  pursued  further. 

d)  Most  important  of  all,  it  should  be  realized  that  controlled  inter¬ 
action  between  users  and  the  data  base  is  only  a  necessary  condition  for  its 
security;  it  is  by  no  means  sufficient.  There  are  many  more  problems  to  be 
solved  before  one  gets  a  (reasonably)  secure  data  base  system.  For  example, 
methods  for  generation  and  manipulation  of  schemas  must  be  formulated. 
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Abstract 


The  protection  of  privacy  of  data  bases  is  discussed.  The 
main  results  of  the  paper  are:  a)  The  conventional  access-matrix 
model,  frequently  used  for  the  specification  of  privacy  measures, 
is  found  not  to  be  suitable  for  data  bases,  b)  The  access  control 
mechanism  commonly  vised  to  enforce  the  privacy  measures  of  data  bases 
is  found  not  to  be  powerful  enough,  since  there  are  privacy  measures 
which  cannot  be  enforced  by  it.  The  paper  argues  that  it  is  necessary 
to  impose  restrictions  on  the  user’s  program  which .interacts  with  the 
database.  .■«  -M  •  ■  :  •  - 
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Introduction 


In  spite  of  the  special  importance  of  privacy  in  data  bases, 
most  of  the  theoretical  work  on  privacy  and  security  was  performed  in  the 
context  of  operating  systems.  Some  of  the  principles  developed  in  these 
studies  were  then  adopted  for  application  in  data  bases,  without  due  regard 
to  the  fundamental  differences  between  these  two  subject  matters.  An 
example  of  such  an  adoption  is  the  access-matrix  model  which  was  developed 
for  operating  systems  [1,2],  and  was  then  adopted  as  the  conceptual  frame¬ 
work  for  protection  of  data  bases  as  well,  (see  [3]  for  example). 

One  of  the  conclusions  of  this  paper  would  be,  however,  that  in 
spite  of  the  apparent  success  of  the  access-matrix  model  in  operating 
systems,  it  is  not  a  suitable  model  for  data  bases.  The  point  that  we. 
are  trying  to  make  is  that  the  subject  of  protection  in  data  bases  has 
some  unique  aspects  which  deserve  an  independent  study.  Some  of  these 
aspects  will  be  discussed  in  this  paper.  ;  '■*. 

As  is  implied  by  the  title,  there  is  no  intention  to  conduct 
a  comprehensive  study  of  privacy  protection  in  this  paper,  we  will  be 
just  making  several  comments.  .  In  these  comments  we  will  address  ourselves 
to  two  aspects  of  privacy  protection.  First,  the  specification  of  the 
"privacy  state".  Namely,  how  does  one  specify  what  it  is  that  a  given 
user  is  allowed  to  do  to  the  data  base,  and  which  information  can  he 
get  from  it.  The  second  aspect  which  will  concern  us  is,  the  enforcement 
of  the  privacy-state. 
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.  Oh  the  Specification  of  Privacy  States 


The  prevailing  approach  to  the  specification  of  the  privacy 
state  of  a  system  is  essentially  the  following:  Assuming  that  there  is 
a  finite  number  of  distinguishable  objects  in  the  system,  and  that  there 
is  a  finite  set  of  potential  users  (or  classes  of  them),  all  we  have  to 
do  is  to  specify  which  operations  can  every  user  apply  to  every  object. 

One  way  to  represent  that  is  by  means  of  a  matrix,  typically  called 
access-matrix.  The  element  A.  .  of  such  a  matrix  would  be  the  list  of 
operations,  or  accesses t  which  user  i  is  allowed  to  apply  to  object  j. 

An  equivalent  model,  which  is  frequently  more  convenient,  is  the  en¬ 
vironment  or  capability  model.  According  to  this  model,  every  user  -who 

interacts  with  the  system  operates  within  an  environment  E  which  is 

*  *  •"  * 

essentially  a  set  of  rights.  Every  right  in  E  is  a  pair  (a,q),  where  q 
is  an  object  in  the  system  and  a  is  an  access  made,  or  a  name  of  an 
operation.  The  pair  (a,q)  serves  as  a  right,  for  the  user  operating  with¬ 
in  the  environment  E,  to  apply  a  to  q.  ^ 

Although  this  model  for  privacy  specification  was  initially 
introduced  for  operating  systems  [1,2],  it  was  adopted  by  many  researchers 
as  a  conceptual  framework  for  the  protection  of  data  bases  as  well,  (see 
[3],  for  example).  This  is  unfortunate,  however,  because  as  we  will  show  be 
low  the  access  matrix  model,  or  the  equivalent  capability  modelt  is  not 
general  enough,  and  is  particularly  inadequate  for  protection  of  data 
bases.  First,  let  us  consider  an  example. 


(1)  This  model  can  be  generalized,  in  order  to  cope  with  "value  dependent" 
privacy  measures,  as  follows:  The  right  (a,q)  can  be  conditioned  on  a 
predicate,  which  may  be  an  arbitrarily  complex  procedure. 


Let  EXCH(x,y)  be  an  operator  which  exchanges  its  two  arguments, 
provided  that  they  are  of  the  same  type  t  (whatever  such  an  "exchange" 
may  mean).  Let  a,  a’,  b,  b'  be  objects  of  type  t,  and  let  U  be  a  user 
who  is  allowed  to  exchange  a  with  a'  and  b  with  b',  but  has  no  right  to 
manipulate  these  objects  in  any  other  way.  It  is  quite  obvious  that 
this  privacy  measure  cannot  be  specified  by  means  of  the  formalism 
presented  above.  The  best  one  can  do  is  to  allow  U  to  apply  the  operator 
EXCH  to  all  four  objects,  by  providing  him  with  the  "rights":  (EXCH,  a), 
(EXCH,  a1),  (EXCH,  b),  (EXCH,  b').  But  this  is  too  permissive,  it  would, 
for  example,  allow  U  to  exchange  a  with  b. 

More  generally  the  privacy  state  of  a  system  can  be  specified  by 
means  of  an  access  matrix  if  the  primitives  available  to  the  user,  for 
\  interaction  with  the  system,  are  all  operations  on  single  objects.  As  it 
is  usually  the  case  in  operating  systems,  when  these  primitives  can  be 
'?  considered  to  be  the  various  access  modes  like  "read  access",  "write 
.  access",  etc.  However,  as  was  illustrated  by  the  EXCH  example,  the  access 
matrix  model  is  not  powerful  enough  to  deal  with  primitives  which  operate 
on  a  number  of  objects.  To  specify  that  a  user  is  allowed  to  apply  an 
operation  p  to  the  objects  we  should  use  something  like  a-tuple 

(p,  q",...qn)  rather  than  the  pair  (a,q)  of  the  capability  model.  For 
instance,  the  privacy  state  of  our  example  might  be  specified  by  the  follow 
ing  two  triples: 

(EXCH,  a,  a')  ,  (EXCH,  b,  b'). 

Now,  the  point  is  that  the  primitives  operations  which  are  avail¬ 
able  to  the  user  of  a  data  base  are  sometimes  high  level  procedures  which 
operate  on  several  objects;  indeed,  it  has  been  shown  in  [5]  that  such 
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! .  A  Model  for  User-database  Interaction 

In  this  section  we  will  describe  a  schematic  model  of  the 
process  of  user-database  interaction,  which  will  serve  as  a  framework  for 
the  subsequent  discussion  of  enforcement  of  privacy  in  data  bases. 

Let  D  be  a  data  base,  and  U  one  of  its  users.  According  to  the 
Data  Base  Task  Group  report  [4]  the  user  should  not  "see"  the  data  base  D 
itself,  but  an  abstract  image  D'  of  it.  D'  would  ideally  contain  only 
those  parts  of  D  which  are  relevant  to  U,  and  in  a  form  most  suitable  for 
him.  The  definition  of  such  an  image  is  usually  called  subschema  and 
will  be  denoted  by  £.  In  order  to  interact  with  the  data  base  the  user 
must  first  connect  himself  to  a  certain  £,  (there  would,  typically,  be 
many  of  them  in  a  given  data  base),  such  connection  would  generate  the 
environment  in  which  the  user's  program  would  operate.  We  will  denote  the 
user's  program  by  II,  or  H(u)). 

There  are  many  issues  which  must  be  discussed  in  order  to  turn 
the  above  into  a  meaningful  model  for  user-database  interaction.  At 
this  point  we  will  consider  just  one  of  them:  the  primitives  operations 
which  should  be  available  to  the  user  for  the  interaction  with  the  data 
base.  According  to  the  conventional  approach,  that  of  the  DBTG[4],  in 
particular,  these  primitives  are  essentially  update  and  retrieval  opera¬ 
tions ;  the  same  kind  of  operations  which  are  traditionally  used  to  mani¬ 
pulate  files.  However,  data  bases  are  not  files,  and  update  and  retrieval 
operations  are  not  suitable  to  manipulate  them.  One  reason  for  that, 
which  was  discussed  in  [5],  is  that  in  order  to  maintain  the  privacy  and 
integrity  of  the  data  base,  the  user  must  be  provided  with  higher  level 


operators  which  manipulate  the  data  base  in  some  predesigned,  presumably 
correct,  way.  These  operators,  which  will  be  called  D-operator,  or  D- 
function,  have  a  central  role  in  the  formation  of  the  abstract  image  of 
the  data  base  which  should  be  accessible  by  the  user-  The  D-operations 
should,  therefore,  be  specified  in  the  sub-schema,  (see  also  figure  1). 

In  general,  a  D-operator  may  have  two  types  of  effects:  It  may  affect 
the  data  base  itself,  and  it  may  generate  information  into  the  storage  space 
of  the  user's  program  which  invoked  it,  such  information  will  be  called  the 
outcome  of  the  D-operation.  In  other  words,  the  oi.tcome  of  a  D-operator 
is  the  information  retrieved  from  the  data  base.  r  ■  • 


3.  On  the  Enforcement  of  Privac 


The  conventional  approach  to  interaction  with  data  bases,  as 
outlined  above,  provides  a  basic  framework  for  privacy  protection,  which 
can  be  viewed  as  a  two- level  mechanism:  First  there  are  privacy  re¬ 
strictions  as  to  which  sub-schemas  can  be  connected  to  the  programs  of 
a  given  user,  and  there  should  be  a  mechanism  which  enforces  these  re¬ 
strictions.  The  rest  is  up  to  the  sub-schema  itself.  It  is  the  role  of 
the  sub-schema  as  a  privacy  enforcer  which  will  concern  us  here. 

According  to  the  conventional  approach,  that  of  the  DBTG  [ 4 ] 
in  particular,  the  sub-schema  acts  essentially  as  an  access-control 

€ 

mechanism:  It  has  an  authority  to  decide  which  parts  of  the  data  base 
can  be  accessed  by  II,  and  which  operations  can  be  applied,  to  the  data 
base,  but  it  has  no  authority  over  what  happens  inside  the  user's  program 
itself.  In  particular,  once  a  piece  of  information  is  transmitted  into 
the  storage  space  of  II,  it  is  automatically  released  from  the  control  of 
the  data  base  and  of  its  privacy  rules.  •*  : :  "  *  * 

This  may  seem  to  be  the  natural  approach  to  protection,  indeed 
the  term  "access  control"  is  frequently  used  as  a  synonym  for  "protection 
But  as  we  will  show  in  this  paper,  the  access-control  mechanism  has  some 
inherent  limitations,  and  cannot  be  used  as  a  universal  privacy  enforcer. 
We  will  see  that  some  privacy  measures  can  be  enforced  only  by  imposing 
restrictions  on  what  happens  inside  the  user's  program,  or  are 
much  easier  to  enforce  with  such  a  control  over  II. 

There  are,  essential  ly,  two  problems  with  the_. access  _cont to 1 
mechanism  as  the  privacy  enforcer;  one  of  them  will  be  treated  in  the 
next  section  and  the  other  is  introduced  below  by  an  example: 


Consider  a  medical  data  base  D,  and  let  P  be  a  set  of  patient's 

names  in  it.  Let  ...  Aj.  be  D-functions  defined  over  the  members  of  P. 

(A^  are  "functions"  in  the  set  theoretical  sense  of  the  term,  one  can 

also  view  A^(q),  for  q  c  P,  as  the  i-th  attribute  of  q) .  Let  the  user 

U  be  a  doctor,  and  let  P* (U)  be  the  set  of  all  patients  of  doctor  U, 

(P'(U)  is  a  subset  of  P).  Let  p  be  the  following  privacy  rule:  "U 

should  have  no  access  to  patient  names  which  do  not  belog  to  P'fW,  nor 

% 

to  the  attributes  of  such  patients".  How  can  this  privacy  rule  be  en¬ 
forced? 

First  one  may  try  to  enforce  the  rule  p  simply  by  providing  U 
with  the  partial  image  of  the  data  base  which  contains  the  names  of  his 
patients  only.  This  can  be  done  as  follows.  Let  MYPAT  be  a  D- function 
provided  to  U  by  the  sub-schema  to  which  he  is  attached.  Suppose  that 
MYPAT,  when  invoked  by  II (U) ,  returns  as  its  outcome  the  next  name  from 
P*(U),  (whatever  "next"  may  mean).  Assuming  that  this  is  the  only  way 
for  U  to  retrieve  elements  from  P,  the  rest  of  our  privacy  rule  may  seem 
to  be  automatically  satisfied.  Namely,  a  request  to  retrieve  A^(q)  can 
be  honoured  without  further  checking,  because  q  can  be  nothing  but  a 
member  of  P'(U).  .Unfortunately,  however,  this  is  not  the  case.  Even 
if  U  can  get  only  names  of  his  own  patients  from  the  data  base,  he  may 
still  be  able  to  get  names  of  other  patients  from  an  outside  source, 
or,  he  may  simply  "invent"  a  name.  Thus,  U  has  the  potential  ability  to 
invoke  A^(q)  for  q  f.  P'(U). 

From  the  above  it  seems  that  the  only  way  to  guarantee  that  U 
does  not  get  the  attributes  of  a  patient  q  /t  P'(U),  is  to  check  if  q  is 
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actually  a  member  of  P'(U)  every  time  that  A^(q)  is  invoked.  This,  how¬ 
ever,  is  a  very  wasteful  solution,  it  means  for  example  that  the  member¬ 
ship  of  q  in  P'(U)  may  have  to  be  checked  several  times  for  the  same  q. 

To  understand  the  nature  of  our  problem  let  us  look  at  it  from  a 
more  general  point  of  view. 

Let  F  be  a  D-function,  and  v  a  variable  in  the  storage  space  of 
II.  Suppose  that  F  is  invoked  by  II  and  that  the  outcome  of  F  is  stored 
in  v.  One  can  say  that  the  variable  v  carries  two  types  of  information 
in  it:  First  there  is  the  set  of  bits  actually  stored  in  v,  which  we 
will  call  the  explicit  information  in  v.  In  addition,  v  carries  an 
important  implicit  information ,  which  is  the  fact  that  the  content  of  v 
was  generated  by  the  D- function  F;  in  a  sense,  this  implicit  information 
provides  the  interpretation  for  the  explicit  information  stored  in  v.  For 
instance,  in  our  example  above,  the  outcome  of  MYPAT  is  not  just  a  string 
of  bits,  it  is  known  to  be  the  name  of  one  of  the  patients  of  U.  The 
existence  of  such  implicit  information  is  so  natural  and  obvious,  that 
one  hardly  gives  any  thought  to  it.  However,  consider  the  following 
situation.  .  '  -  '  . 

Let  G  be  another  D-function  in  our  data  base,  which  admits  one 
parameter.  Suppose  that  G  is  invoked  by  II,  with  v  as  a  parameter.  The 
invocation  G(v)  obviously  communicates  to  the  function  G  the  explicit 
information  in  v,  that  is  what  parameters  arc  for.  But  the  implicit  in¬ 
formation,  which  gives  to  v  its  interpretation,  is  not  communicated  to  G; 
because  G  has  no  way  of  knowing  how  was  the  content  of  v  generated.  Coming 
back  to  example  1,  if  A^(q)  was  invoked  by  IT,  there  is  no  way  for  the 
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function  to  know  that  the  content  of  q  is  in  fact  "the  name  of  a 
patient  of  U"  without  actually  checking  it.  Namely,  for  the  function 
the  parameter  q  is  nothing  but  a  string  of  bits,  its  implicit  in¬ 
formation  is  lost. 

To  summarize;  the  implicit  information  carried  by  the  outcome  of  a 
D-function  into  the  storage  space  of  II,  cannot  be  carried  back  into  the 
data  base.  This  loss  of  information,  which  as  we  saw  may  cause  difficulties 
in  the  enforcement  of  certain  privacy  rules,  is  due  to  the  complete  freedom 
that  II  has  in  the  manipulation  of  its  own  storage  space.  As  we  will  show 
next,  one  can  maintain  the  credibility  of  such  implicit  information  by  im¬ 
posing  restrictions  on  what  the  user's  program  can  do  with  information 

retrieved  from  the  data  base.  ; • 

\  •  ' 

Consider  the  following  modifications,  borrowed  from  [6], 
to  the  conventional  model  of  interaction  with  data-bases.  Suppose  that 
the  outcome  of  a  D-operation,  when  transmitted  to  the  storage  space  of 
II,  can  be  marked,  or  braided,  by  one  of  a  set  of  brands  specified  in  the 
sub-schema.  (This  branding  process  should  be  under  the  complete  control 
of  the  sub-schema,  in  a  manner  not  to  be  specified  here).  The  branded 
information-objects,  although  they  are  stored  in  the  storage  space  of  II, 
cannot  be  manipulated  freely  by  it.  Rather,  they  are  subject  to  a  set  of 
rules,  to  be  called  D-rules,  provided  by  the  sub-schema  which  in  effect, 
specify  the  operations  which  can  be  applied  to  the  branded  objects. 

Every  brand  which  appears  in  the  sub-schema,  also  induces  a  new  "type" 
into.  H,  in  the  following  sense:  If  3  is  a  brand  in  E,  then  one  may  de¬ 
clare,  in  II,  a  variable  to  be  of  "type  3"  much  in  the  same  way  as  one  . 
declares  variables  to  be  of  "type  integer",  say. '  Avariable  of  type 
3  may  contain  only  3-branded  information  objects. 
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Coming  back  again  to  example  1:  Suppose  that  the  outcome 
of  MYPAT  is  branded  by  the  brand  S.  Suppose  also  that  the  D-rules  pro¬ 
vided  by  Z  allow  II  to  use  B-branded  objects  non-destructively,  but  do  not 
allow  it  to  modify  them  in  any  way.  Under  these  assumptions  the  privacy 
restriction  p  can  be  enforced  simply  by  requiring  that  only  variable  of 
"type  B"  would  be  used  as  parameters  of  the  D-functions  Because, 

due  to  the  restrictions  above,  a  variable  of  type  B  can  contain  only  names 
of  patients  of  U.  We  may  say  that  the  restrictions  on  the  manipulation  of 
8-branded  objects  preserves  the  implicit  information  in  them. 

Thus,  we  saw  that  certain  privacy  measures  can  be  enforced  more 
efficiently  if  the  user  program  can  be  controlled  by  the  data  base.  We 
will  now  see  that  for  a  certain  class  of  privacy  restriction  such  . control 
is  essential.  -  ’  • 


-13- 


.*  .« 


4.  “Intentional  Resolution  Power"  of  Privacy  Protection 

One  of  the  most  important  characteristics  of  privacy  protection 
mechanisms  is  the  fineness  in  which  the  privacy  measures  can  be  specified, 
which  may  be  called  the  resolution  power  of  the  privacy  protection.  One 
may  be  interested  in  resolution  along  two  orthogonal  "dimensions".  One 
of  them,  whose  importance  is  usually  well  appreciated,  is  the  specification 
of  which  parts  of  the  data  base  should  be  revealed  to  the  user;  the  other 
dimension,  which  will  be  called  intentional  resolution ,  is  related  to 
"what  is  the  user  allowed  to  do  with  a  piece  of  information  revealed  to 
him".  It  is  this  second  aspect  of  the  resolution  power  of  privacy  protec¬ 
tion  which  will  concern  us  here. 

It  may  seem  that-  intentional  resolution  is  mainly  a  legal 
matter,  not  within  the  realm  of  computer  technology,  because  once  a 
piece  of  information  is  revealed  to  a  human  user,  there  is  no  way  for  the 
data  base  system  to  impose  restrictions  on  how  it  is  used.  Indeed,  in 
the  traditional  approach  to  privacy  protection,  the  privacy  enforcer  is 
viewed  as  a  kind  of  mediator  between  the  data  base  and  the  user,  whose  job 
is  to  decide  which  information  can  be  revealed  to  the  user.  There  is  no 
place  for  intentional  resolution  under  this  approach.  Actually,  however, 
the  data  base  does  not  usually  communicate  information  directly  to  the 
human  user,  but  to  his  program.  Moreover,  much  of  the  information  re¬ 
trieved  from  the  data  base  is  needed  only  for  a  certain  computation  to  be 
performed  by  the  user's  program,  and  there  is  no  need  for  the  user  himself 
to  see  it.  To  comply  with  the  "need  to  know"  principle,  such  information 
should  be  released  to  the  program  JI,  but  II  should  be  prevented  from  revealing 
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this  information  to  the  human  user.  There  is  a  difficulty  here,  however; 
under  the  conventional  approach,  the  data  base,  or  its  privacy  enforcer, 

has  no  more  control  over  the  user's  program,  than  it  has  over  the  human 
user  himself.  In  particular,  once  a  piece  of  information  is  trans¬ 
mitted  to  II  there  is  no  way,  short  of  a  manual  audit  of  the  program,  to 
prevent  II  from  printing  this  information,  for  the  user  U  to  see. 

It  is  clear,  therefore,  that  in  order  to  provide  any  degree  of 
intentional  resolution,  the  privacy  enforcer  must  be  able  to  impose  re¬ 
strictions  on  the  computations  performed  inside  the  usct's  program,  and 
not  only  on  the  D-operators  invoked  by  it.  This  is  again  the  conclusion 
of  section  3,  derived  in  a  different  way.  The  implementation  of  inten¬ 
tional  resolution  is  discussed  in  some  detail  in  [7],  This  section  will 
be  concluded  by  two  examples  which  are  intended  to  demonstrate  the  practi¬ 
cal  inportance  of  intentional  resolution. 

•  '  ..  *  ;  V  -.  „ 

Example  2  ;  \ 

Consider  a  data  base  D,  and  a  highly  confidential  set  of  records, 

F  *  {f},  in  it.  Let  U  be  a  programmer  who  is  commissioned  to  apply  a 
transformation  T  to  every  record  f  e  F  and  to  store  the  transformed  records 
back  into  the  data-base,  as  a  set  F’.  Suppose  that  due  to  the  confidentiality 
of  F  we  do  not  want  its  content  to  be  revealed  to  the  programmer  U  himself, 
or  to  leak  in  any  form  or  shape  to  the  outside  world.  In  other  words,  we 
want  the  programmer  to  eat  the  cake ,  but  not  to  have  it  in  his  stomach . 

This  case  represents  an  important  class  of  privacy  problems.  It 
is  this  author's  belief  that  the  most  serious  threat  to  the  privacy  of 
data  bases  does  not  come  from  outsiders  who  arc  using  ingenious  techniques 
to  penetrate  the  system,  but  from  insiders  who  have  the  data  base  at  their 
fingertips.  Every  data-base  system  employs  "mnintenance  programmers"  whose 
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job  is  to  perforin  routine  transformations  and  manipulations  of  various 
files.  Most  of  these  programmers  have  no  need  to  actually  see  all 
the  information  manipulated  by  them,  and  they  should  be  prevented  from 
doing  so. 

Example  5 


Consider  a  medical  data  base  D.  Let  PAT  =  {p}  be  a  set  of 
patient  names  in  D.  Let  T  =  {t}  be  a  set  of  treatment  codes,  and  let 
FEE(t)  be  a  function,  in  the  set-theoretical  sense,  which  gives  the  fee, 
in  dollars,  that  has  to  be  paid  for  treatment  t.  Suppose  also  that 
for  every  patient  p  there  is  a  list,  TLIST(p) ,  of  all  the  treatments  re¬ 
ceived  by  p.  * 


Let  U  be  a  clerk  who  has  to  write  a  program  to  compute  the 
charge  c(p)  of  patient  p,  in  order  to  send  him  his  bill.  c(p)  is  given  by 


;  r ; '  c(P) « I  FEECt) 
• t€  TLIST(p) 


It  is  clear  the  U  must  have  an  access  to  the  list  of  treatments  received 
by  p,  in  order  to  compute-  c(p).  At  the  same  time,  however,  TLISTCp) 
is  a  confidential  information  which  the  clerk  has  no  business  seeing  him¬ 
self,  nor  should  he  be  able  to  leak  it  to  anybody  else. 

Thus  TLIST(p)  should  be  revealed  to  a  program  written  by  our 
clerk,  but  for  a  limited  purpose  only. 

For  a  discussion  of  the  realization  of  the  intentional  resolu¬ 


tion  required  in  these  two  examples,  the  reader  is  referred  to  [7]. 
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Conclusion 

Two  issues  of  privacy  protection  in  data  bases  were  discussed. 
First,  it  has  been  shown  that  the  conventional  access-matrix  technique 
for  the  specification  of  the  "privacy  state"  of  a  system  is  not  as 
general  as  it  is  sometimes  believed  to  be,  and  it  is  particularly  un¬ 
suitable  for  data  bases.  A  simple  generalization  of  the  matrix  model  was 
proposed. 

The  second  issue  has  to  do  with  the  enforcement  of  privacy.  It 
has  been  shown  that  not  all  privacy  measures  can  be  enforced  by  access- 
control  alone,  and  that  it  is  necessary  for  the  privacy  enforcer  to  have 
some  control  over  the  user  program  itself.  The  realization  of  such  a  control 
was  not  discussed  in  this  paper,  but  it  is  safe  to  say  that  it  would  require 
some  radical  changes  in  the  conventional  approach  to  the  user-database 
interaction.  The  subject  was  discussed  further  in  [5,6,7],  but  there  is  much 


more  to  be  done. 
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One  of  the  most  elegant  and  powerful  concepts,  recently  developed 
for  programming  languages  is  the  concept  of  abstract  data  type.,  it 
seems  to  have  been  invented  by  the  designers  of  SIMULA  language  [1], 
and  received  its  final  touch  (to  date)  in  a  paper  by  Liskov  and  Zilles 
[2]  (we  will  refer  to  this  paper  by  LIZ).  Abstract  data  type  was  de¬ 
fined  by  LIZ  as  "a  class  of  objects  which  is  completely  characterized 
by  the  operations  which  may  be  performed  on  those  objects."  To  imple¬ 
ment  this  concept  they  introduced  a  new  linguistic  construct  called 
operation  cluster.  The  cluster  serves  as  a  structural  template  for 
the  objects  of  the  type  t  being  defined  by  it.  In  addition,  the 
cluster  contains  the  definition  of  a  set  of  procedures  which  are  to 
serve  as  the  characteristic  operators  of  type  t.  That  is  to  say,  an 
object  of  type  t  can  be  manipulated  only  by  means  of  these  operators. 

The  usefulness  of  the  cluster  concept  is  unquestionable.  In 
addition  to  being  an  important  tool  for  well  structured  programming, 
it  provides  the  programmer  with  the  very. desirable  capability  of  im¬ 
posing  restrictions  on  his  own  program.  But  some  of  the  claims  made 
by  Liskov  and  Zilles  about  their  cluster  concept  are  not  completely 
justified.  The  following  is  a  quotation  from  their  paper:  "We  betieve 
that  the  above  concept  captures  the  fundamental,  properties  of  abstract 
obj'ects",  since,  they  say:  " The  behavtor  of  an  object  ts  captured  by 
the  set  of  [its]  characterising  operations. "  One  objection  to  this  rather 
strong  claim  rests  on  the  following  observation: 

The  behavior  of  a  data  object  cannot  always  be  fully  characterized 
by  the  operators  which  are  applicable  to  this  object  alone.  One  might 
have  to  take  into  account  the  possible  interactions  of  the  given  object 
with  other  objects,  which  may  belong  to  the  same,  or  to  different  classes. 

The  difficulty  here  is  that  an  interaction  between  two  or  more  objects, 
cannot  always  be  reduced  to  a  sequence  of  legal  operations  on  the  objects 
which  participate  in  the  interaction.  Therefore,  as  we  will  see  more 
specifically  below,  an  interaction  between  objects  cannot  always  be  implemented 
within  the  framework  proposed  by  LIZ.  An  example  may  clarify  this  point. 
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Let  JOB  and  PERSON  be  two  classes  of  objects  (abstract  data 
types),  and  let  the  objects  j  and  p  be  instances  of  these  classes,  (j 
and  p  may  be  also  viewed  as  "identifiers  of",  or  "pointers  to"  the 
corresponding  objects).  Let  R  be  a  one-to-one  relation  between  the 
two  classes,  which  specifies  "who  is  appointed  to  which  job".  One 
way  to  implement  such  a  relation  is  the  following:  Let  j. person  and 
p.job  be  components  of  the  objects  j  and  p,  such  that  j. person  points 
to  the  PERSON  object  assigned  to  j,and  p.job  is  defined  symmetrically. 

Now  suppose  that  we  have  to  impose  a  certain  discipline  on  the  appoint¬ 
ments.  According  to  the  philosophy  advanced  by  LIZ,  the  following 
technique  is  implied:  The  clusters  which  define  the  classes  JOB  and 
PERSON  should  not  provide  any  operators  for  direct  update  of  the 
components  j. person  and  p.job  (namely,  from  outside  of  these  clusters, 
j. person  and  p.job  would  be  "read  only"  variables).  Instead,  there 
should  be  an  operator  appoint  (p,/J  which  performs  the  appointment  of 
person  p  to  job  j,  under  the  discipline  at  hand.  Thus  the  behavior 
of  objects  of  types  JOB  and  PERSON  cannot  be  fully  captured  just  by 
the  operators  defined  on  these  objects  alone,  one  must  consider  also 
the  operator  appoint  which  is,  in  effect,  an  interaction  between  a 
(j,p)  pair.  Moreover,  wider  these  conditions  the  operator  appoint 
cannot  be  implemented  in  a  language  based  on  the  cluster  principle. 

That  is  so  because  the  operator  appoint  has  to  change  the  components 
j. person  and  p.job  of  j  and  p.  But  the  first  can  be  changed  only  with¬ 
in  the  cluster  which  defines  JOB,  while  the  second  can  be  modified 
only  within  the  PERSON  cluster.  Thus  there  is  simply  no  environment  in  ^ 
which  appoint  can  operate. 

Two  solutions  to  this  problem  suggest  themselves:  First,  one 
can  remove  the  relation  R  from  the  body  of  the  objects  j  and  p;  In¬ 
stead  of  using  the  components  j. person  and  p.job,  one  can  define  R 
as  a  set  of  pairs  ((j,p)),  using  the  mathematical  definition  of  "rela¬ 
tion".  To  manipulate  this  relation  one  does  not  need  any  privileged 
access  to  the  objects  themselves  since  only  the  pointers-  to  the  objects 
are  involved.  Thus,  the  operator  appoint  can  be  defined  outside  of  the 
clusters  of  JOB  and  PERSON.  However,  such  decentralization  of  the  data 
which  is  relevant  to  the  objects  at  hand  is  not  compatible  with  the  under¬ 
lying  philosophy  advanced  by  LIZ.  incidentally,  the  above  suggests  that 
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in  order  to  define  the  behavior  of  a  class  of  objects,  one  may  have 
to  specify  where  pointers  to  these  objects  can  be  stored.  The  char¬ 
acteristic  operators  of  objects,  and  even  the  possible  interactions  between 
objects  may  not  be  enough.) 

The  second  solution  to  our  problem  calls  for  more  sophisticated 
scope  rules  than  those  suggested  in  LIZ.  For  example  the  procedure 
appoint  can  be  implemented  if  it  is  possible  to  give  it  a  privileged 
access  to  both  j. person  and  p.job,  without  giving  such  an  access  to 
the  rest  of  the  program. 

In  spite  of  its  limitations  the  cluster  may  be  an  ideal  construct 
for  most  programming  languages.  Considering  its  simplicity,  it 
accomplishes  amazingly  much  so  that  it  can  be  rated  as  a  "best  buy". 
However,  the  limitation  of  the  cluster  concept  becomes  crucial  in  a 
programming  environment  where  security  is  essential,  such  as  the  con¬ 
struction  of  operating  systems  and  data  bases.  It  is  interesting  to 
point  out  in  this  context  that  studies  of  protection  in  programming 
systems  tend  to  do  the  same  oversimplifications  made  in  LIZ.  For 
example,  Lampson's  protection  theory  [3]  specifies  the  "protection 
state"  of  a  system  by  listing  all  the  accesses  (operators)  which  are 
applicable  to  every  object.  This  again  ignores  interactions  between 
objects  and  is  not,  therefore,  general  enough.  (This  problem,  in  the 
context  of  data  bases,  was  discussed  by  the  author  in  [4].)  The  paper 
of  Morris  [5]  which  studies  protection  in  programming  languages  seems 
to  suffer  from  the  same  problem. 
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_  that  tills  is  too  simplistic  a  view,  but  first  we  will  try  to  understand 

(1)  Me  will  frequently  use  the  abreviation  DB  for  the  term  "data  base".  what  is  an  "operation  on  the  data  base". 


lot  G  be  another  D-operator  in  our  data  base,  which  adaits  one  parameter. 
Suppose  that  G  is  invoked  by  n,  with  v  as  a  parameter.  The  invocation  G(v) 
obviously  communicates  to  the  operator  G  the  explicit  information  in  vj  but 


2.5.2.  The  problem  of  value-dependent  rules 


(X)  Note  that  the  saving  here  can  be  measured  again  by  the  "value"  of  the 
implicit  information  of  a  p  retrieved  from  PAT(U). 


at  "compile  time",  see  however  below. 


tree PO  •  However,  this  argument  does  not  take  into  account  the  possibility 


The  Problem:  Consider  a  data  base  D,  and  a  highly  confidential  set  of 


' —  transformation  T.  For  that  we  will  need  a  new  linguistic  structure  in  L, 

O]  The  example  to  be  discussed  here  was  originally  presented  in  [6]  t0  be  called  "confidence -nodule",  to  be  introduced  next, 

it  is  repeated  here  because  it  exhibits  an  interesting  generalization 

of  our  0-rules,  and  for  the  sate  of  completeness.  Let  M  be  a  normal  module  of  a  program,  such  as  block  or  procedure*  We 


G)  Many  details  are  left  out  of  the  following  discussion,  for  brevity. 


or  programmed,  by  means  of  a  language  which  has  the  necessary  protection 


i  role  of  the  base-language  in  our  model,  in  the  following  sense:  To 

1)  CODASYL  Data  Base  Task  Group  (DBTG)  April  71  report  (Available  from  AQ 

ign  a  module  of  the  DB,  say  a  D-operator,  one  has  to  work  under  a  certain 

2)  Minsky,  N.,  "On  interaction  with  data  bases"  Proc.  of  the  ACM  SIGFIDET 

just  like  any  external  user.  The  module  would  therefore  be  written  in  workshop  "on  data  description  access  and  control", 1974. 
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1 .  What  is  a  Data  Base? 

A  data  base  is  often  viewed  as  a  kind  of  glorified  file  which 
allows  for  the  storage  of  complex  data  strucutures,  and  which  can 
be  shared  by  many  users  who  have  different  needs.  But  there  is 
a  more  fundamental  difference  between  data-bases  and  files  then 
just  the  complexity  of  data  or  the  generality  of  its  retrieval. 

The  traditional  file  is  essentially  a  passive  collection  of  coded 
data  which  is  devoid  of  any  intrinsic  meaning.  Indeed  the 
interpretation  of  the  data  stored  in  a  file  is  entirely  up 
to  its  users.  The  data-base,  on  the  other  hand,  is  usually  used 
as  a  model,  or  representation,  of  some  system  in  the  real  world. 

For  example,  a  corporate  data  base  is,  in  some  sense,  a  model 
of  a  corporation;  and  it  must  reflect  some  of  its  structual 
and  behavorial  properties.  This  is  not  just  a  matter  of  record¬ 
ing  correctly  every.thing  which  happens  within  the  corporation. 

For  example,  when  we  "tell"  the  DB  that  an  employee  is  fired, 
we  expect  all  necessary  adjustments  to  be  made  automatically, 
so  that  only  current  employees  will  be  on  the  payroll  of  the 
corporation  at  every  moment  in  time.  In  short,  we  expect  a  DB  to 
"take  care  of  itself"  to  a  certain  extent;  it  therefore  cannot  be 
a  completely  passive  collection  of  data.  But  if  a  data-base  may 
contain  procedural  components  and  not  just-  data,  what  kind  of  thing 
is  it?  .In  what  way  is  it  different  from  what  we  usually  call  pro¬ 
grams?  (It  might  have  never  occurred  to  the  reader  to  compare 
data-bases  with  programs,  but  as  we  will  show  later  the  two  con¬ 
cepts  have  more  in  common  than  meets  the  eye.)  In  an  attempt  to 
clarify  the  concept  of  data-base  I  will  now  offer  a  definition  for 
it.  The  definition  is  an  oversimplification,  as  any  definition  of 
such  a  fuzzy  concept  must  be;  it  will  emphasize  certain  characteris¬ 
tics  of  data-bases,  at  t:<e  expense  of  other,  equally  important, 
properties . 

Definition:  A  data-base  is  a  model  (or  representation)  of  some 
system  in  the  real  world,  which  satisfies  aj.1  of  the  following 
properties : 

(a)  The  model  contains  a  large  amount  of  coded  information. 

(b)  It  has  a  long  life  time  (say,  from  several  days  to 
several  years). 

(c)  The  model  can  be  examined  and  interrogated  at  any  moment 
of  its  life  time. 

(d)  The  model  changes  primarily  in  response  to  operations 
applied  to  it  from  the  outside. 
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The  first  sentence  of  thi  •'  finition  states  the  general  objective 
of  a  data  base.  This  ::-i  ye  is  not  specific  to  data  bases, 

however.  For  example,  a  jajration  can  be  modeled  by  a  sim¬ 
ulation  program,  not  juuM-.‘-‘7  a  DB.  The  specificity  of  this  def¬ 
inition  to  data-bases  is  ided  by  properties  (a)  to  (d)  ,  the 

first  of  which  we  assume  to  be  tacitly  understood. 

To  see  how  the  other  properties  relate  specifically  to  data-bases 
consider  again  a  corporate  DB.  Such  a  DB  functions  as  a  model-, 
or  a  representation,  of  a  corporation  for  long  periods  of  time. 

At  every  moment  during  this  time  the  model  can  be  interrogated, 
which  corresponds  to  retrievals  of  information  from  the  DB.  Note 
that  this  is  quite  different-  from  the  behavior  and  usage  of  tra¬ 
ditional  programs.  • 

A  program  is  used  primarily  as  a  kind  of  input -output  engine? 
it  is  executed  for  its  output,  and  it  is  not  usually  examined  while 
in  the  process  of  computation.  Indeed,  the  active  period  of  a 
program,  what  may  be  called  its  life  time,  is  relatively  short 
and  insignificant. 

Another  difference  between  data-bases  and  programs  is  provided  by 
property  (d)  which  states  that  a  DB  changes  primarily  in  response 
tp  operations  from  outside,  update  operations  if  you  will.  This 
is  in  sharp  contrast  with,  say,  a  simulation  model  of  a  system 
whose  dynamic  behavior  is  determined  primarily  by  the  model  it¬ 
self.  This  property  also  introduces  a  new  dimension  into  the 
sufficiently  difficult  problem  of  correctness  in  programming  systems 
When  we  write  a  program  we  have  to  make  sure  that  the  program 
will  do  exactly  what  we  want  it  to  do,  which  is  difficult  enough. 

But  the  desigher  of  a  DB  has  an  additional  problem  at  hand.  He 
does  not  know  in  advance  how  the  DB  will  change  in  time?  this  is 
up  to  the  users  who  will  interact  with  it.  At  the  same  time,  it 
is  up  to  the  DB  designer  to  establish  the  invariance  of  certain 
structural  and  behavioral  characteristics  of  the  DB  whatever  the 
users  of  the  DB  might  do.  In  other  words,  the  integrity  of  the 
DB  must  be  protected  against  the  essentially  unpredictable  inter¬ 
action  with  the  outside  world.  (Of  course,  this  problem  is  not 
peculiar  to  data  -bases,  it  cvtists  to  a  certain  degree  in  many 
programming  systems,  particularly  in  operating  systems;  but  the 
need  for  protection  is  particularly  acute  in  the  case  of  data-  bases.) 

Most  of  the  current  research  on  data-bases  is  directed  towards 
various^  implications  of  properties  (a)  to  (d)  .  People  are  most 
concerned  with  subjects  like  the  physical  and  logical  representation 
of  complex  data,  techniques  and  languages  which  allow  flexible 
retrieval  from  the  data-base,  etc.  But  it  seems  that  the  objective 
of  data  bases,  to  be  a  model  of  a  system  in  the  real  world,  is 
somewhat  discarded,  or  at  least,  is  not  sufficiently  emphasized. 

True,  the  protection  of  the  integrity  of  data  bases  is  often  stated 
as  one  of  the  main  objectives  of  data  base  systems.  But  in  most 
cases  this  is  hardly  more  than  lip  service,  supported,  at  best, 
by  simple  consistency  checking.  But  if  there  is  a  lesson  to  be 


learned  from  the  long  experience  with  programming  in  general,  and 
with  operating  systems  in  particular,  it  is  that  protection  is  not 
an  add-on  feature  but  must  be  designed  deeply  into  the  fundamental 
structure  of  a  system*  This,  to  the  best  of  my  knowledge,  is  us¬ 
ually  not  done  in  the  case  of  data-bases. 


In  this  paper  we  will  examine  some  aspects  of  the  architecture 
of  data-bases  having  in  mind  primarily  the  need  to  protect  their 
integrity  with  respect  to  the  real-life  system  which  they  are  sup¬ 
posed  to  represent.  The  conclusions  of  this  paper  are  not  new, 
most  of  them  are  borrowed  from  ideas  and  principles  developed  in 
the  context  of  operating  systems  and  programming  languages.  If 
there  is  any  originality  in  this  paper  it  is  the  application  of 
these  well  known  principles  to  data-bases. 

To  remove  any  possible  misunderstanding  it  should  be  pointed  out 
that  we  are  dealing  here  with  the  concept  of  data-base  not  data-base 
management  system  (DBMS) .  The  relationship  between  these  two  con- 
cepts  is  somewhat  analogous  to  the  relationship  between  a  program 
and  its  compiler. 

2.  A  Data-Base-Language 

It  is  well  known  that  the  structure  of  programs  is  strongly  affected 
by  the  properties  of  the  programming  language  in  which  they  are 
written.  A  similar  statement  is  probably  true  for  data  bases  as 
well.  Most  of  this  paper  will,  accordingly,  be  concerned  with  the 
language  used  for  the  construction  of  data-bases.  We  will  begin 
by  reviewing  the  language  proposed  by  one  of  the  most  influential 
works  on  data  bases,  the  Data  Base  Task  Group  (DBTG)  report  [1 1  - 

Two  languages  are  introduced  by  the  DBTG  report:  The  Data  Defin¬ 
ition  Language  (DDL),  which  is  a  declarative,  non-procedural  language, 
to  be  used  for  the  definition  of  a  DB;  and  the  Data  Manipulation 
Language  (DML)  to  be  used  for  interaction  with  an  existing  DB. 

This  dichotomy  of  languages,  which  is  somewhat  analogous  to  the 
sharp  distinction  made  in  COBOL  between  the  "data  division"  and 
"procedure  division",  seems  to  imply  that  data-bases  are  essentially 
passive  structures,  since  they  are  to  be  defined  b.y  a  language 
which  does  not  feature  any  data-manipulation  capabilities.  This 
approach  certainly  does  not  agree  with  our  view  of  a  data-base  as 
a  model  of  a  possibly  dynamic  system.  Moreover,  it  is  not  even 
compatible  with  the  modern  approach  to  data  structures  in  general, 
as  we  will  see  later.  Indeed,  the  DBTG  report  did  not  really  view 
data-bases  as  completely  passive  structures.  To  compensate  for  the 
lack  of  procedural  capabilities  in  its  DDL,  it  allows  for  the  in¬ 
corporation  of  the  so  called  DB-procedures  within  the  data  base. 

But  the  report  did  not  specify  how  such  procedures  should 
be  incorporated  into  a  DB,  or  in  which  language  they  should  be 
written  (should  it  be  a  DML)?  These  questions  are  generously  left 
for  the  implementor,  in  spite  of  the  fact  that  the  declarative 
features  of  the  DDL  were  described  in  great  detail.  It  appears  that 
the  authors  of  the  DBTG  report  considered  the  DB-procedure  just  as 
an  additive  feature  of  marginal  importance. 

It  is  my  contention,  however,  that  the  .language  to  be  used  for  the 
design  of  data-bases  must  be  an  integration  of  declarative  and  pro¬ 
cedural  capabilities#  as  most  programming  languages  are;  one 


may  call  such  a  language  a  Data-Base-Language  (DBL).  An  obvious 
reason  for  having  such  a  lar*p'--»ge  is  that  if  procedures  are  at 
all  necessary  for  the  design  data-bases,  there  seems  to  be 
no  good  reason  to  introdui  via  the  back  door,  as  is  done 

by  the  DBTG  report.  But  the.:-  is  a  more  subtle  reason  for  that. 

The  DB-procedures  are  the  dy»--",:c  components  of  a  DB.  If  we  want 
to  have  any  control  over  the  dynamic  behavior  of  the  data  base 
we  must  be  able  to  control  the  DB-procedures  themselves.  In 
particular,  one  should  be  able  to  restrict  a  given  procedure  as 
to  what  it  can  do  to  the  rest  of  the  DB.  It  appears  that  the 
clearest  way  to  achieve  that,  is  to  have  all  DB-procedures  be 
written  in  a  given,  well-defined,  DBL.  The  manner  in  which  such 
a  language  can  be  used  in  order  to  impose  certain  disciplines  on 
the  behavior  of  a  DB,  will  be  discussed  in  the  rest  of  this  paper. 

3.  "Information  Objects"  in  Data  Bases". 

What  was  said  about  the  data-base  being  a  model  of  some  system  in 
the  real  world  should  be  true  also  for  the  individual  components, 
or  records,  stored  in  a  DB.  At  least  some  of  them  must  represent 
specific  objects  in  the  real  world.  For  example,  we  might  have  a 
data  structure  which  represents  an  employee  in  a  corporation,  and 
another  one  which  represents  a  job.  The  behavior  of  these  data 
structures  within  the  DB  must  reflect,  in  some  way,  the  behavior 
of  the  objects  they  represent  within  the  corporation  itself.  For 
instance,  one  should  be  able  to  hire  or  fire  an  employee,  or  to 
assign  him  to  a  certain  job;  but  one  should  not  be  able  to  manipu¬ 
late  arbitrarily  a  data-structure  which  represents  an  employee,  or  . 
a  job.  Thus,  it  seems  that  we  need  the  ability  to  form  data  structures 
which  cen  be  manipulated  only  in  a  certain  predefined  way.  Data 
structures  which  have  this  property  will  be  called  here  information 
objects. 

Note,  however,  that  being  an  information  object  is  not  really 
a  property  of  the  data  structure  itself,  but  of  the  "computing 
environment"  in  which  it  exists,  which  should  prevent  any  illegal 
manipulation  of  'the  object.  Such  a  computing  environment  can  be 
created  by  a  programming  language,  as  was  demonstrated  by  a  num¬ 
ber  of  researchers. 

In  a  recent  paper  by  Liskov  and  Zilles  [3],  a  language  is  described 
which  features  a  linguistic  contruct  called  duster  which  serves 
as  a  template  for  a  class  of  information  objects.  The  cluster  con¬ 
tains  a  description  of  a  conventional  data-structure,  together  with 
a  set  of  procedures  which  are  defined  on  that  structure.  For  a  given 
cluster  c,  there  is  a  way  to  generate  objects  using  c  as  a  template. 

All  such  objects  are  said  to  belong  to  class  c.  Now,  the  crux  of  the 
matter  is  that  an  object  of  class  C  can  be  manipulated  only  by  moans 
Of  operators  defined  within  the  cluster/  which  turns  these  objects 
into  information  objects,  according  to  our  definition. 

Note  that  this  is  not  an  easy  proposition;  it  is  not  just  a  matter 
of  adding  yet  another  -feature  to  an  existing  language.  The  entire 
language  must  be  very  carefully  designed  in  order  to  guarantee  that ~ 
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an  object  of  class  C  is  never  manipulated  by  an  operator  which 
does  not  belong  to.it.  Note  also  that  the  combination  of  both 
declarative  and  procedural  statements  in  the  same  cluster  is 
necessary  for  the  formation  of  these  information  objects. 

We  will  now  try  to  demonstrate,  by  an  example,  the  potential 
usefulness  of  information  objects  for  data-bases,  assuming  that 
this  facility  is  supported  by  the  DBL  at  hand. 

*  .  • 

Example:  Conservation  of  Money 

One  type  of  object  which  has  to  be  represented  in  any  financially 
oriented  DB,  is  money.  One  of  the  most  important  properties  of 
real  money  is  that  it  cannot  be  created  out  of  nowhere,  at  least 
not  in  a  legally  operated  establishment,  nor  should  it  be  allowed  to 
disappear  into-  thin  air.  This  property  may  be  called  conservation 
of  money  and  it  should  be  reflected  in  the  behavior  of  the  data- 
structure  which  represents  money  in  a  DB. 

To  impose  conservation  of  money  on  a  DB,  we  will  represent  money 
by  means  of  information  objects  to  be  called  safes,  a  safe  is  a 
kind  of  money-variable  which  can  be  accessed  and  manipulated  only* 
by  means  of  the  following  operators: 

Content (s)  returns  the  number  of  dollars  currently  stored 

in  safe  s. 

move  (s  s  ^,k)  if  s2,s2  are  safes  and  *  is  a  positive 

number  such  that  content  (sj)  &k,  then  this 
operator  "transfers"  units  of  money  (dol¬ 
lars)  from  s2  t0  s2 .  (Namely,  it  leaves 
the  content  of  s2  smaller  by  *,  and  that  of 
s2  larger  by  k) . 

• 

The  operator  move  represents  the  act  of  money  changing  hands  in  the 
real  world.  In  order  to  represent  the  flow  of  money  into  the  system 
we  use  another  class  of  information  objects,  to  be  called  source,  a 
source  is  similar  to  a  safe  except  that  any  amount  can  be  moved 
from  a  source  into  a  sink,  but  no  money  can  be  moved  into  a  source. 
The  content  of  a  source  would  be  negative,  its  absolute  value  being 
equal  to  the  total  amount  of  money  moved  out  of  it. 

Under  these  conditions,  and  assuming  that  the  content  of  all  sources 
and  safes  is  initially  zero,  it  is  easy  to  see  that  the  sum  of  all 
safes  and  sources  in  the  system  is  always  zero. 

In  spite  of  the  obvious  usefulness  of  being  able  to  impose  such 
a  law  of  conservation  on  a  DB,  it  is  not  quite  sufficient.  For 
example,  one  would  like  to  impose  certain  disciplines  on  how  the 
money  flows  between  the  various  safes,  and  how  it  is  used  within 
the  DB.  We  will  return  to  these  problems  in  the  next  section. 


•Except  for  operators  which  generate  and  destroy  safes,  which  are 
not  discussed  here. 
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4.  Environments  of  Execution 


As  was  just  demonstrated,  the  ability  to  create  information  objects 
which  can  be  manipulated  only  by  means  of  given  operators  can 
help  in  enforcing  useful  disciplines  on  the  behavior  of  a  DB,  but 
this  ability  alone  is  certainly  not  sufficient.  One  should  also 
be  able  to  specify  "who"  can  apply  which  operator  to  a  given  ob¬ 
ject.  Such  a  capability  is  fundamental  to  the  various  protection 
schemes  recently  developed  for  operating  systems  (2) ,  it  also  forms 
the  basis  for  many  of  the  techniques  used  for  the  protection  of 
data-bases  against  users  who  interact  with  it.  For  example,  ac¬ 
cording  to  the  DBTG  proposal,  a  DB-user  operates  within  an  "environ¬ 
ment"  formed  by  a  sub-schema  which  specifies,  in  effect,  which 
parts  of  the  DB  the  user  is  allowed  to  get,  and  how  he  is  allowed 
to  access  them.  But  although  this  does  provide  a  DB  with  certain 
protection  against  its  users,  it  does  not  protect  it  against  itself. 

A  DB  is  manipulated  not  only  by  its  users,  but  by  its  own  procedures 
as  well;  and  it  is  a  well  known  principle  in  the  design  of  large 
systems  that  no  module  should  be  allowed  to  access  more  of  the  sys¬ 
tem  than  it  needs,  in  order  to  perform  its  function.  Thus,  the 
DBTG  proposal  should  have  assigned  a  sub-schema  to  every  DB-procedure 
in  order  to  limit  the  procedure  as  to  what  it  can  do  to  the  rest 

of  the  DB.  This  kind  of  protection  scheme  was  proposed  by  Wulf, 

Jones  and  others  (2),  for  the  design  of  operating  systems.  A1 - 
though  their  techniques  must  be  modified  before  they  can  be  applied 
effectively  to  data  bases,  the  basic  philosophy  has  universal 
validity,  and  is  briefly  described  below  with  some  changes,  and 
slightly  different  terminology. 

According  to  Jones'  and  Wulf's  proposal,  every  activity  (or  what 
is  usually  called  "process  of  computation")  in  a  system  is  carried 
out  from  a  certain  environment  E,  which  can  be  formally  described 
as  a  set  of  pairs  E  =  (g,a)  ,  where  q  is  the  identifier  of  an 

information  object  in  the  system,  and  a  is  one  of  the  access-modes 

defined  for  it.  The  pair  (q,a)  is  called  capability  (or  right). 

A  capability  (q,a)£  E  serves. as  a  right  for  a  process  which  operates 
under  E  to  exercise  access  a  to  object  q,  in  the  following  sense. 
Every  operator  defined  as  an  information  object  in  the  system, 
expects  the  environment  from  which  it  was  invoked  to  have  certain 
capabilities.  Namely,  the  operation  is  carried  out  only  if  the  en¬ 
vironment  in  which  the  requesting  activity  resides  contains  the 
required  capabilities.  An  example  may  clarify  this  point. 

Consider  again  our  money  example.  Let  get  and  put  be  two  access 
modes  defined  over  a  safe  such  that  the  operator  move  (slrs2tk) 
can  only  be  carried  out  if  the  calling  environment  has  the  capa¬ 
bilities  ( s 2 , get)  and  (s2,  put)-  This  allows  us  to  specify  not 
only  which  safes  a  given  user  can  access,  but  the  direction  in 
which  he  can  move  money  between  them. 

One  of  the  most  interesting  aspects  of  Jones'  model  is  its  treatment 


•It  should  be  pointed  out  that  even  in  this  respect  the  sub-schema 
of  the  DBTG  report  has  serious  deficiencies,  as  is  shown  in  (4). 


of  procedures:  Every  procedure  is  defined  within  its  own  en¬ 
vironment,  which  obviously  does  not  depend  on  the  environment 
of  the  potential  caller  of  the  procedure.  The  capabilities  in 
this  environment  are  called  the  static  capabilities  of  the  pro¬ 
cedure.  In  addition,  when  the  procedure  is  called,  it  may  re¬ 
ceive  some  additional,  dynamic  capabilities,  from  the  caller's 
environment,  by  means  of  its  parameters. 

It  is  quite  clear  that  such  protection  schemes  can  greatly  en¬ 
hance  the  reliability  of  a  large  programming  system.  But  I 
would  like  to  demonstrate  specifically  the  usefulness  of  such  a 
scheme  in  the  context  of  data  bases,  using  for  that,  our  money 
example . 

In  the  previous  section  we  saw  how  to  establish  a  global  "con¬ 
servation  of  money" in  a  corporate  DB.  But  more  than  that  is  re¬ 
quired  in  order  to  model  the  behavior  of  money  in  the  real  world. 

For  example,  assuming  that  paychecks  are  issued  under  the  direct 
supervision  of  the  corporate  DB,  one  may  require  that  whenever 
a  check  is  issued  on  the  amount  of  d  dollars,  the  total  amount  of 
money  represented  in  the  DB  is  reduced  by  D.  The  implemention  of 
this  and  other  characteristic  properties  of  money  are  discussed 
below. 

Consider  a  DB-procedure  PAY  (e,s)  which  is  designed  to  issue  a 
check  payable  to  employee  e  for  the  amount  contained  in  safe  s. 

The  following  assumptions  are  made. 

a)  PAY  has  a  static  and  exc lusive  put  right  to  a  safe  called 
cash,  (namely,  it  has  the  capability  (cash,  put)  in  its 
environment ) . 

b)  No  environment  in  the  DB  has  a  get  right  to  cash.  (The 
safe  cash  is,  therefore,  a  sink  of  money). 

c)  PAY  has  a  dynamic  get  right  to  the  safe  s  given  to  it  as  a 
parameter,  and  it  has  np  other  right  to  any  other  safe. 

d)  PAY  is  the  only  procedure  which  is  able  to  actually  print 
a  check. 

Now,  if  the  procedure  PAY  is  known  to  perform  the  operation  move 
(s, cash, content (s) )  after  printing  a  check  for  the  amount  of  con¬ 
tends),  then  we  are  assured  that  every  check  printed  by  the  DB 
is  balanced  by  a  suitable  amount  of  dollars  being  transferred  to 
the  safe  cash.  Moreover,  content (cash)  is  equal  to  the  total  amount 
of  dollars  which  was  paid  by  checks. 

This  example  can  be  further  refined  to  establish  local  conservation 
of  money,  as  follows:  consider  an  environment  E,  which  may  be  the 
environment  of  some  user,  or  of  a  DB-procedure.  Suppose  that  E 
contains  the  get  right  to  a  single  safe  sq,  and  both  the  get  and  put 
rights  to  the  set  of  safes  sp..sn,  Suppose  also  that  no  other 
environment  has  the  put  right  to  $p..sn,  and  that  E  has  the  right 
to  invoke  the  PAY  procedure.  E  may,  for  example,  be  the  environ¬ 
ment  used  by  the  clerks  in  the  accounting. of f ice  of  a  certain 


department  in  the  corporation.  It  is  clear  that  whoever  operates 
under  E,  has  only  as  much  money  available  to  him  as  he  can  get  from 
Sg.  which  is  his  only  external  source  of  money.  For  example  he- 
can  never  pay  more  in  checks  than  what  is  given  to  him  via  sg. 

Thus,  sg  can  be  used  by  an  environment  which  happens  to  have  the 
put  right  to  it,  as  a  way  to  allocate  budget  for  E.  Similarly,  E 
may  grant  some  of  his  own  money  to  some  other  environment  via  one 
of  the  safes  s^. 

It  is  clear  that  by  these  kind  of  restrictions  on  the  manipulation 
of  safes  one  can  model  many  of  the  properties  associated  with  money 
in  the  real  world.  A  monetary  information  system  built  in  such  a 
way  also  lends  itself  very  nicely  to  auditing.  The  auditor  can 
know  much  about  the  flow  of  money  inside  the  corporation  just  by 
examining  the  various  environments  and  some  DB-procedures  such  as 
our  PAY  procedure. 

The  implementation  of  the  protection  scheme  described  above  is  be¬ 
yond  the  scope  of  this  paper.  I  wish  only  to  suggest  that  it  should 
be  entrusted  to  the  Data-Base-Language.  This  language  has  a  unique 
position  from  which  it  can  control  what  happens  within  the  DB,  be¬ 
cause  the  DB  itself  is  presumably  defined  in  it.  In  this  sense, 
the  DBL  will  play  the  role  of  the  protection  kernel  of  operating 
systems  proposed  by  Wulf  and  Jones.  (For  the  reader  who  is  puzzled 
by  the  idea  that  a  language  can  be  used  for  protection,  I  would  like 
to  point  out  that  in  a  certain  sense  a  programming  language  can  be 
viewed  as  a  set  of  capabilities  which  are  provided  to  a  program  writ¬ 
ten  in  this  language.  This  view  about  languages,  and  its  implica¬ 
tions,  to  the  ability  of  a  language  to  play  a  major  role  in  protec¬ 
tion  is  discussed  in  (4) . 

Conclusion  ’ 

A  DB  has  been  viewed  as  a  dynamic  model  of  some  given  system, 
rather  than  as  a  passive  collection  of  data.  This  paper  was  con¬ 
cerned  primarily  with  some  implications  of  this  point  of  view  to 
the  language  used  for  the  construction  of  data-bases.  One  obvious 
implication  is  that  a  Data-Base-Language  must  have  procedural  capa¬ 
bilities.  A  somewhat  more  subtle  observation  made  by  this  paper, 
is  that  a  DBL  should  have  certain  features  which  would  enable  a  DB 
designer  to  impose  some  discipline  on  the  behavior  of  his  DB,  under 
its  interaction  with  users.  There  are,  however,  other  important 
issues  concerning  the  Data-Base-Language ,  which  were  not  discussed 
here.  In  particular,  there  is  the  problem  of  the  control -structure 
of  such  a  language.  There  are  indications  that  the  conventional 
control-structure  of,  say,  ALGOL-like  languages,  would  not  be  suf¬ 
ficient.  For  example,  one  needs  tools  to  cope  with  the  parallelism 
in  the  activity  of  data-bases.  In  addition  non-conventional  con¬ 
trol  structures  such  as  '’event-sequencing”  (or  "demons”)  ,  which 
were  proposed  for  data-bases  by  Morgan  (5) ,  and  which  are  being  used 
in  several  Al-languages,  appear  to  be  very  promising.  These  and 
other  issues  must  be  investigated  in  the  context  of  the  already  ex¬ 
isting  knowledge  about  the  structure  and  manipulation  of  complex 
data  (1,5). 
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Traditionally,  privacy  protection  in  database  systems 
is  understood  to  be  the  control  over  what  information  a 
given  user  can  get  from  a  database.  This  paper  is  con¬ 
cerned  with  another,  independent,  dimension  of  privacy 
protection,  the  control  over  what  a  user  is  allowed  to  do 
with  a  piece  of  information  supplied  to  him  by  the  data¬ 
base.  The  ability  to  condition  the  supply  of  information 
on  its  intended  use  is  called  here  “intentional  resolution” 
of  privacy  protection. 

The  practical  importance  of  intentional  resolution  is 
demonstrated  by  several  examples,  and  its  realization  is 
discussed.  It  is  shown  that  intentional  resolution  can  be 
achieved,  but  that  it  involves  a  radical  change  from  the 
traditional  approach  to  the  process  of  user-database 
interaction.  In  particular,  it  appears  to  be  necessary  for 
the  database  to  impose  a  certain  amount  of  control  over 
the  internal  behavior  of  users’  programs  which  interact 
with  it.  A  model  for  user-database  interaction  which 
admits  such  a  control  is  developed. 
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1  In  this  paper,  we  will  use  the  term  "privacy  protection"  as  a 
restriction  on  the  retrieval  process  only.  This  is  admittedly  a  limited 
sense  of  the  term,  since  updates  of  the  database  should  also  be 
subject  to  privacy  restrictions.  Note  also  that  many  writers  are  using 
the  term  ''security"  for  what  we  call  "privacy." 
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1.  Introduction 

Traditionally,  privacy  protection  in  database  sys¬ 
tems  is  understood  to  be  the  control  over  what  informa¬ 
tion  a  given  user  can  get1  from  a  database.  This  paper 
is  concerned  with  another,  independent,  dimension  of 
privacy  protection,  the  control  over  what  a  user  is  al¬ 
lowed  to  do  with  a  piece  of  information  supplied  to 
him  by  the  database.  The  ability  to  restrict  the  use  of 
information  retrieved  from  a  database  will  be  called 
“intentional  resolution  of  privacy  protection.’’ 

It  may  seem  to  the  reader  that  international  resol¬ 
ution  is  mainly  a  legal  matter,  not  within  the  realm  of 
computer  technology,  because  once  a  piece  of  informa¬ 
tion  is  revealed  to  a  human  user,  there  is  no  way  for 
the  database  system  to  impose  restrictions  on  how  to 
use  it.  However,  the  database  does  not  usually  com¬ 
municate  information  directly  to  the  human  user  but  to 
a  program  written  by  him.  In  fact,  much  of  the  infor¬ 
mation  retrieved  from  a  database  is  not  intended  for 
the  programmer’s  eyes,  but  for  his  program.  For 
example,  it  can  happen  that  confidential  information  is 
needed  in  the  user’s  program  as  a  means  for  getting 
other,  sometimes  less  confidential  data,  which  is  what 
the  user  is  really  after.  Were  it  possible  to  prevent  the 
user’s  program  from  revealing  to  the  user  himself 
certain  information  given  to  it  by  the  database  (by 
printing  the  information  itself  or  any  computed  result 
of  it),  one  would  be  able  to  release  to  the  program  data 
which  for  privacy  reasons  should  not  be  released  to  the 
programmer  himself.  In  the  absence  of  such  intentional 
resolution  capability  one  is  forced  to  release  either  too 
much  or  too  little  information  to  the  requesting 
program. 

Consider,  for  example,  a  programmer  who  works 
for  the  “database  administrator.”  Since  it  is  the  job 
of  such  a  programmer  to  maintain  the  information  in 
the  database,  he  must  be  given  almost  universal  per¬ 
mission  to  retrieve  data  from  it.  Thus,  although  most 
of  these  programmers  have  no  need  to  actually  see  the 
information  manipulated  by  the.n,  they  can  usually  do 
so,  which  according  to  mahy  observers,  presents  the 
most  serious  threat  to  the  privacy  of  databases.  We 
would  like,  therefore,  to  be  able  to  prevent  a  program¬ 
mer  from  actually  seeing  certain  information  which  is 
released  to  his  program.  In  other  words,  we  sometimes 
want  the  programmer  to  “ eat  the  cake  blindfolded." 
This  is  one  aspect  of  intentional  resolution 

Unfortunately,  intentional  resolution  is  fundamen¬ 
tally  incompatible  with  the  traditional  approach  to 
privacy  protection,  which  is  based  primarily  on  access 
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control .*  That  is,  the  “privacy  enforcer”  is  usually 
viewed  as  a  kind  of  mediator  between  a  database  and 
its  “user,”  where  by  the  term  “user"  we  mean  the 
human  user  together  with  his  program  (sec  Figure  1(a)). 
Such  a  privacy  enforcer  has  the  authority  to  decide 
which  information  could  be  transmitted  to  this  “user 
complex,”  but  it  has  no  say  on  how  such  information  is 
to  be  used,  either  by  the  human  user  or  by  his  program. 
Indeed  the  privacy  enforcer  has  no  more  control  over 
the  user’s  program  than  it  has  over  the  user  himself. 

It  follows  that  in  order  to  achieve  any  degree  of 
intentional  resolution  it  is  necessary,  in  addition  to  the 
normal  access  control  protection,  to  give  the  database 
some  control  over  what  happens  inside  the  program 
which  interacts  with  it  In  particular,  there  should  be  a 
way  to  restrict  the  program  in  what  it  can  do  with  the 


Fig.  1,  Two  approaches  to  privacy  protection. 


(a)  The  traditional  approaches  to  privacy  protection  do  not 
distinguish  between  the  human  user  and  his  program. 


ENFORCER 


(b)  Here  there  is  a  clear  distinction  between  the  user  and  his  pro¬ 
gram.  The  user’s  program  is  under  (partial)  control  of  the  privacy 
enforcer  of  the  database,  so  that  the  program  cannot  communicate 
to  the  user  every  piece  of  iniormation  it  gets  from  the  database. 


PRIVACY 
E  NFORCER 


information  retrieved  from  the  database  (sec  Figure 
1(b)).  As  we  will  show  in  this  paper,  a  useful  level  of 
protection  can  be  achieved  by  means  of  only  a  modest 
degree  of  control  over  the  user  program,  which  can  be 
imposed  quite  efficiently,  often  without  any  run  time 
checking.  The  approach  to  be  proposed  is  based  on 
well-known  techniques  of  protection  in  programming 
languages  [II)  and  in  operating  systems  [5),  but  it  is 
believed  to  be  novel  in  the  context  of  databases  and  it 
calls  for  a  radical  change  in  the  traditional  approach 
to  user  database  interaction. 

In  Section  2  we  summarize  the  basic  principles  on 
which  the  conventional  access  control  protection  mecha¬ 
nisms  are  based.  The  limitations  of  this  kind  of  protec¬ 
tion  are  illustrated  by  an  example.  In  Section  3,  some 
relevant  aspects  of  programming  languages  are  dis¬ 
cussed.  Our  model  for  user-database  interaction  is 
presented  in  Section  4,  and  its  use  for  privacy  protec¬ 
tion  is  discussed  in  Section  5. 

Finally,  in  Section  6,  the  scope  of  application  of  our 
protection  technique  is  discussed.  In  particular,  it  is 
pointed  out  that  this  technique  is  not  intended  for  all 
types  of  users  of  a  database. 

2.  Access  Control  Protection  Mechanism 

We  begin  by  presenting  a  schematic  and  simplified 
model  for  the  process  of  user  database  interaction  (see 
Figure  2),  which  we  believe  is  consistent  with  the  con¬ 
ventional  approach  to  databases.  The  main  participants 
in  this  interaction  are  the  user  ( U )  and  his  program 
(II),  on  one  hand;  and  the  database  (D)  on  the  other. 
However,  in  general,  the  user  is  not  presented  with 
the  database  itself,  but  with  an  image  of  it,  which 
contains  only  part  of  the  database,  possibly  in  some 
abstract  form,  [I,  2,  3).  Following  the  DBTG  report 
[1],  we  will  use  the  term  subschema  for  the  specification 
of  such  an  image,  denoting  it  by  Z.  (The  image  of  D 
which  is  formed  by  a  specific  Z  will  be  denoted  D/2 
(see  Figure  2)).  There  is  no  general  agreement  as  to  the 
exact  nature  of  the  subschema  concept,  but  from  the 
viewpoint  of  protection  it  can  be  described  as  the  speci¬ 
fication  of  which  parts  of  the  database  a  given  user  is 
allowed  to  access,  and  what  operations  he  is  allowed  to 
apply  to  them.  In  other  words,  the  subschema  is  a  col¬ 
lection  of  “capabilities”’  to  be  granted  to  a  certain 
user  or  to  a  class  of  users.  Of  course,  the  database  would 
usually  have  many  users  with  diverse  needs  and  author¬ 
ity;  it  must  therefore  contain  many  subschemas  to 
support  the  various  necessary  images.  To  interact  with 
a  database  the  user  must  first  be  connected  to  one  such 
subschema.  Assuming  that  the  user  has  an  unforgeable 

'This  is  true  only  in  the  context  of  databases.  More  sophisti¬ 
cated  protection  techniques  are  being  developed  for  operating 
systems,  (see  |5|,  for  example). 

*  At  this  point  we  are  using  the  term  "capability”  in  its  collo¬ 
quial  sense.  A  more  technical  meaning  will  be  given  to  this  term 
later. 
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F*.  2.  An  illustration  of  the  conventional  view  of  user -database 
interaction. 
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identification,  this  connection  can  itself  be  under  the 
control  of  a  protection  mechanism  which  decides  which 
'subschemas  can  be  connected  to  which  user. 

The  process  of  user-database  interaction  can  be 
viewed  as  a  sequence  of  “operations"  applied  by  the 
user  program  II  to  the  database  D,  which  may  be 
either  retrieval  requests  or  update  operations.4  We  will 
refer  to  any  such  operation  as  a  D-operation. 

The  access  control  protection  mechanism  can  now 
be  defined  as  the  validation  that:  (a)  each  and  every 
.D-operation  issued  by  n  is  permitted  by  the  subschema 
2  to  which  the  user  is  connected;  (b)  information  to 
be  transmitted  by  D  to  II,  in  a -response  to  a  D-opera¬ 
tion,  belongs  to  the  image  D/2. 

Without  going  into  the  details  of  such  a  mechanism, 
the  following  can  be  stated:  From  the  point  of  view  of 
the  access  control  protection,  the  user  program  (or 
process  of  computation)  can  be  considered  as  a  "black 
box”  which  issues  D-operations,  the  internal  behavior 
of  II  being  irrelevant  to  this  kind  of  protection.  This  is 
true  in  principle,  even  if  for  efficiency  reasons  one 
decides  to  examine  the  user  program  in  order  to  identify 
the  potential  D-operations,  and  check  their  validity  at 
compile  time.  Such  a  technique,  proposed  by  several 
writers  [3,  4],  can  still  be  considered  as  a  version  of 
access  control  technique,  since  it  is  not  interested  in 
the  behavior  of  II  itself,  only  in  its  D-operations.  Some 
of  the  limitations  of  an  access  control  protection  mech¬ 
anism  will  now  be  illustrated  by  an  example. 

Consider  a  binary  tree  stored  in  D  which,  in  set- 
theoretical  notation,  is  defined  to  be  the  set  T  of  “nodes" 
together  with  the  three  functions  DATA,  LSON,  and 
RSON,  which  are  defined  over  T.  For  a  given  node 
n  6  T,  the  value  of  the  function  DATA(n)  is  considered 
to  be  the  "data"  associated  with  the  node  n;  the  func¬ 
tion  LSON(n)  returns  the  node  n'  Q  T  which  is  the 

4  These  may  be  high-level  operations  loaded  with  semantics, 
such  as  "fire  an  employee"  (see  (2J>. 


"left  son”  of  n,  and  similarly  for  RSON(n).  Now  let  A' 
be  a  certain  node  in  T,  and  let  U  be  a  user  whom  we 
wish  to  grant  a  read-access  only  to  the  subtree  of  T 
whose  root  is  A,  which  we  will  denote  by  trcc(N).  How 
can  such  a  restriction  be  imposed? 

In  order  to  make  tree(N)  accessible  to  U,  it  is 
enough  to  provide  the  user  with  the  node  N,  and  to 
allow  him  the  use  of  the  three  functions  DATA,  LSON, 
RSON.  It  might  seem  that  with  just  these  four  items 
the  user  cannot  get  to  any  node  outside  of  tree(N). 
This,  however,  is  not  the  case.  Suppose,  for  example, 
our  user  manages  to  get  a  node  identifier  n'  l  tree(N) 
from  an  outside  source.  Since  he  is  allowed  to  use  the 
three  functions  that  are  associated  with  our  tree,  this 
would  give  him  an  access  to  the  entire  subtree  tree(n'). 
The  only  solution  that  an  access  control  protection 
has  to  offer  for  this  problem  is  to  check  the  argument 
of  DATA(n)  for  membership  in  tree(N)  whenever  this 
function  is  invoked.  This  brute  force  protection  tech¬ 
nique  can  become  extremely  inefficient  for  large  trees, 
and  can  be  considered  impractical.  A  potentially  better 
method  is  suggested  by  the  following  observation. 

Let  t  be  a  “type”  defined  in  the  program  n,  and 
suppose  that  we  manage  to  impose  the  following  rules 
on  II: 

Rule  1.  The  only  “things”  which  can  be  stored  in  a 
variable  of  type  t  are  the  node  identifier  N  or  outcomes 
of  the  functions  LSON,  RSON. 

Rule  2.  The  functions  DATA,  LSON,  RSON  can  be 
applied  to  the  variables  of  type  t  only. 

It  is  quite  clear  that  if  II  does  not  violate  these 
rules,  it  cannot  access  any  node  which  does  not  belong 
to  tree(N).  Moreover,  it  should  not  be  too  difficult  to 
impose  such  rules  on  a  program,  because  they  are 
quite  similar  to  the  rules  associated  with  types  in 
programming  languages.  For  example,  there  are  rules 
built  into  Algol  which  guarantee  that  only  integer 
numbers  can  ever  be  stored  in  an  integer  variable,  just 
like  our  two  rules  above  which  guarantee  that  only 
nodes  from  tree(N)  can  be  stored  in  t  variables.  Of 
course,  one  cannot  expect  a  language  to  contain  rules 
for  how  a  specific  user  should  treat  a  specific  data  item 
retrieved  from  a  database.  We  suggest,  however,  that 
such  rules  can  be  induced  into  a  language  at  the  time 
that  the  user  connects  himself  to  a  specific  subschema. 
The  ability  to  induce  such  rules  into  a  language  depends, 
of  course,  on  the  programming  language  at  hand. 
Therefore  our  next  step  is  to  examine  some  relevant 
properties  of  programming  languages. 

3.  Capabilities  Built  into  a  Programming  Language 

In  this  section  we  will  try  to  characterize  the  “capa¬ 
bilities”  which  are  built  into  a  programming  language. 
By  this  we  mean  the  “operational  capabilities”  pro¬ 
vided  by  the  language  to  a  process  of  computation  gen¬ 
erated  by  a  program  written  in  this  language,  rather 
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than  the  “syntactic  capabilities”  which  the  language 
provides  the  programmer.  For  example,  we  will  be 
interested  in  questions  like  what  kind  of  operations  can 
a  computing  process  carry  out,  or  what  can  such  a 
process  do  to  a  certain  type  of  information  object, 
e.g.  to  an  integer  variable.  Such  questions  are  relevant 
to  our  subject  matter  because  when  a  piece  of  informa¬ 
tion  is  transmitted  to  a  user  program  we  would  like  to 
know  what  the  program  can  do  with  it.  In  order  to  be 
able  to  answer  such  questions  we  will  now  develop  a 
model  for  the  “capabilities  of  languages.”  It  should 
be  pointed  out,  at  the  outset,  that  this  model  is  not 
intended  as  a  contribution  to  the  theory  of  languages 
per  se,  but  as  a  tool  for  the  subsequent  treatment  of 
user  database  interaction.  We  begin  by  introducing 
some  basic  concepts  and  notation. 

Let  L  be  a  language,  and  let  IT,  or  11(1),  be  a  process 
of  computation  generated  by  a  program  written  in  L.  If 
we  take  a  snapshot  of  II  at  a  certain  stage  of  its  activity, 
we  can  talk  about  the  information  space  of  II,  to  be 
denoted  by  S,  which  is  the  set  of  all  information  objects 
(or  simply  objects)  which  are  accessible  to  n  at  this 
moment.  By  the  term  object  we  mean,  informally 
speaking,  a  “thing”  which  has  a  state.  The  state  of  an 
object  can  be  observed  and  it  may,  or  may  not,  be 
changeable.  For  example,  the  number  "17”  is  a 
nonchangeable  object,  while  the  state  of  a  “stack”  can 
be  changed  by  means  of  a  "push”  or  a  “pop”  operator. 

It  would  be  convenient  to  consider  some  of  the 
objects  in  S  as  being  primitive  objects  provided  by  L 
to  every  process  II(L),  such  as  the  various  literals  rec¬ 
ognized  by  the  language.  This  set  of  objects  will  be 
denoted  by  SL ■  The  other  objects  in  S  are  generated  by 
II  itself,  as  we  will  see  later. 

It  is  customary  to  classify  the  objects  in  S  by  means 
of  types.  The  concept  of  type  would  be  central  to  our 
model,  but  since  we  will  be  interested  only  in  some  of 
its  aspects,  to  which  we  will  have  a  somewhat  uncon¬ 
ventional  approach,  we  will  avoid  the  term  “type,” 
replacing  it  by  “brand.”  We  assume  that  the  state  of 
every  object  s  €  S  has  two  distinguishable  parts: 
brand(s)  and  value(s).  Here,  value{s)  stands  for  the 
“main  part”  of  the  object  s,  and  brand(s)  is  a  tag  which 
will  be  used  to  classify  the  various  objects  in  S.  For 
simplicity  we  assume  that  there  is  a  fixed  and  finite  set 
of  different  brands  for  a  given  language  L,  to  be  denoted 
by  Bl  .  We  will  use  the  symbol  0  to  denote  a  generic 
brand,  and  barred  capital  letters  to  denote  specific 
brands.  For  example,  we  will  use  7  as  the  brand  associ¬ 
ated  with  integer  numbers,  R  as  the  brand  associated 
with  real  numbers,  T  as  the  brand  associated  with  text 
objects,  etc.  An  object  whose  brand  is  a  certain  0  will 
be  referred  to  as  a  0-object. 

-  For  reasons  which  will  not  be  spelled  out  here  we 
introduce  the  following  convention:  the  language  will 
recognize  a  special  "nuU”  object  which  will  be  treated 
as  if  it  is  branded  by  all  the  brands  in  BL  . 

The  objects  in  S  are  generated  and  manipulated  by 


means  of  a  set  PL  of  primitive  operators  provided  by 
the  language.  Examples  of  such  primitive  operators 
are:  the  operator  which  adds  two  numbers  (ob¬ 
jects),  generating  a  new  number  which  is  equal  to  their 
sum;  or  a  “declare”  operator  which  generates  a  new 
array.  (Note  that  we  do  not  distinguish  between  oper¬ 
ators  that  can  act  at  “compile  time”  and  those  that  act 
at  “run  time”). 

The  process  II  can  now  be  formally  defined  as  a 
sequence  of  operations  of  the  form: 

Jo  <—  p(si ,...,$,)  (for  n  >  0), 

which  is  the  application  of  the  operator  p  r.  Pl  to  the 
objects  si , ....  i.  in  S.  Such  an  operation  may  affect 
the  objects  r,  ;  in  addition  it  generates  a  new  object  s*  , 
to  be  called  the  outcome  of  p,  and  which  may  in  par¬ 
ticular  be  null.  (Note  that  this  is  not  an  “assignment 
statement”;  a  special  assignment  operator  will  be  in¬ 
troduced  later).  We  will  assume,  for  simplicity,  that 
once  an  object  is  generated  into  S,  its  brand  cannot  be 
changed ;  thus  the  operator  p  above  can  change  at  most 
only  the  value  parts  of  objects  s( . 

Under  most  languages  a  computing  process  is  not 
free  to  apply  any  operator  to  any  set  of  objects.  The 
language  usually  has  a  set  of  rules  built  into  it  that 
specify  which  operators  can  be  applied  to  which  objects, 
and  under  which  circumstances.  This  set  of  rules,  to  be 
called  the  application  rules  of  the  language,  will  be 
denoted  by  RL .  Languages  may  vary  widely  as  to  the 
type  and  form  of  their  application  rules;  in  particular, 
a  language  may  have  no  such  rules  at  all,  as  the  follow¬ 
ing  example  shows. 

Let  L  be  the  machine  language  of  a  classical  von 
Neumann  machine.  The  storage  space  S  of  every  n(L) 
is  fixed  in  this  case,  being  the  set  of  memory  cells  of 
the  machine.  The  set  of  operators  PL  available  to  II 
are  the  machine  instructions.  There  are  practically  no 
application  rules  here;  II  is  free  to  apply  any  operator 
to  any  cell.  This  does  not  necessarily  result  in  complete 
anarchy,  since  the  operators  themselves  may  have  their 
own  built-in  rules.  For  example,  although  there  is  no 
way  to  prevent  the  division  operator  from  being  applied 
to  a  zero  denominator,  the  operator  itself  would  usually 
refuse  to  divide  by  zero.  Such  internal  rules,  built  into 
the  operators,  will  not  be  discussed  in  this  paper.  We 
will  look  upon  the  various  objects  and  operators  as 
“black  boxes,”  considering  only  application  rules  which 
are  imposed  by  the  language  from  the  outside,  so  to 
speak.  One  class  of  such  rules  will  be  introduced  later 
in  this  section. 

To  summarize,  we  define  what  we  call  "the  capa- 
bililies'  of  a  language  L”  as  the  four-tuple 
(Si  ,Bt,Pi,  Rl),  where 

SL  is  the  set  of  primitive  objects  in  L, 


1  Note  that  this  definition  of  "capabilities”  is  related,  but  not 
identical,  to  the  meaning  that  this  term  has  in  the  context  of  oper¬ 
ating  systems  (3|. 
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Bl  is  the  set  of  brands  defined  in  L, 

PL  is  the  set  of  primitive  operators  provided  to  every 

n(£), 

Rt  is  the  set  of  application  rules  imposed  on  n(L). 

We  will  now  introduce  a  class  of  application  rules  that 
will  be  useful  to  the  rest  of  this  paper. 

3.1  Sim,  'e  Application  Rules 

We  now  consider  application  rules  which  have  the 
following  general  form: 

r\  A,  <=(/>,  ft, ... ,  0.)  (for  n  >  0) 

where  0,  ~  BL  for  i  =  0,  1,  . .  . ,  n,  and  p  <E  PL  . 

The  rule  r  (r  is  a  label,  used  for  discussion  only) 
serves  two  functions.  First,  the  right-hand  side  of  r 
serves  as  a  right *  for  n(  Z.)  to  invoke  any  operation 
p(sx, .  .  .  ,  s,)  such  that  brand  (s,)  =  0,  for  I  <  i  <  n. 
The  right-hand  side  of  r  will  accordingly  be  called  right 
and  will  be  denoted  by  p.  it  is  assumed  that  no  p  can 
appear  more  than  once  in  RL .  The  second  function  of 
.  the  rule  is  to  determine  the  brand  of  the  outcome  of  an 

operation  p(sx . 5.) :  it  is  to  be  the  do  of  the  rule 

which  contains  the  right  for  this  operation  (by  the 
assumption  above,  there  is  at  most  one  such  rule).  If 
do  is  null  and  “<=”  does  not  appear  in  the  rule,  it  would 
mean  that  no  new  object  is  generated  into  5(11),  even 
if  p  does  have  an  outcome. 

These  rules  are  simple  and  restricted  in  several 
respects;  in  particular;  (a)  the  rules  are  independent  of 
the  values  of  their  arguments,  being  defined  in  terms 
of  the  brands  only;  (b)  the  rules  are  invariant  of  the 
state  of  computation  (for  example,  they  do  not  dis¬ 
tinguish  between  the  compilation  phase  and  the  execu¬ 
tion  phase  of  IIT;  (c)  the  rules  have  “global  validity,” 
so  that  they  cannot  be  used  to  model  any  "name 
scoping.”  Yet  these  "simple  rules"  can  model  a  signifi¬ 
cant  part  of  the  application  rules  of  many  languages. 
For  example,  if  7,  R,  and  C  stand  for  the  brands  of 
integer,  real,  and  complex  objects,  then  the  following 
are  samples  of  the  rules  which  one  might  have ; 

rl:  7  «=  (+,  7,  7), 
r2:  R  <=  (+ ,  7,  R), 
r3:  €<=(+,  C,  O, 
r4:  R*=  ( IM ,  C). 

The  rule  rl  allows  n  to  add  two  integers,  specifying 
that  the  outcome  is  an  integer.  r2  allows  n  to  add  an 
integer  to  a  real  number  (obviously  there  is  a  conver¬ 
sion  to  be  done  here,  but  this  is  irrelevant  to  the  appli¬ 
cation  rules).  r4  allows  II  to  apply  the  operator  JM  to 
a  complex  number,  which  presumably  returns  its 
imaginary  part.  Note  also  that  if  the  set  RL  at  hand 
does  not  contain  the  right  (+,  7,  C),  then  n  cannot  add, 
directly,  an  integer  to  a  complex  number. 

•The  term  "right”  is  borrowed  from  |5|. 

1  Such  a  distinction  is  made  in  most  languages.  For  example, 
in  Fortran  variables  are  generated  only  at  compile  time. 


As  another  example,  suppose  that  we  have  in  L  the 
data  type  “stack  of  integers”  whose  brand  is  S.  Assuming 
the  existence  of  the  two  operators  PUSH  and  POP  in 
PL  ,  we  might  control  the  use  of  stacks  by  the  follow¬ 
ing  rules: 

rl:  (PUSH,  S,  1) 

rl:  1  <=  (POP,  S) 

Note  that  according  to  rl,  PUSH  has  no  outcome. 

In  order  to  get  a  better  approximation  to  realistic 
programming  languages  we  must  introduce  explicitly 
the  concepts  of  variable  and  assignment  operator.  This 
we  will  do  next. 

3.2.  Variables  and  Assignment  Operator 

The  concept  of  “variable”  can  be  introduced  into 
our  model,  intuitively,  as  follows:  a  variable  is  an 
object  whose  value  part  is  another  object  or  the  "name” 
of  such  an  object,  if  sharing  is  desired  (we  will  ignore 
the  distinction  between  these  two  cases).  The  value  of  a 
variable  is  assigned  to  it  by  the  assignment  operator 
“:  =  ”.  In  our  notation  the  assignment  operation  will 
have  the  form  :=  (variable,  object),  and  for  simplicity 
we  assume  that  this  operation  has  no  outcome.  If  a 
variable  appears  as  an  argument  of  an  operation  in 
any  other  context,  then  the  object  which  is  its  value  is 
assumed.  An  important  property  of  a  variable  is  its 
domain,  which  is  the  set  of  all  objects  which  can  pos¬ 
sibly  serve  as  values  of  the  variable.  The  domain  of  a 
variable  is  clearly  determined  by  the  rules  in  RL ,  as  the 
following  example  shows. 

Let  v  and  0  be  brands  in  BL  ,  and  suppose  that  the 
following  rule  exists  in  RL  : 

r-  (:=,v,0) 

This  rule  allows  v-objects  to  appear  at  the  “receiving 
end”  of  an  assignment  statement,  the  other  end  of  which 
is  a  /3-object.  Formally,  this  makes  v-objects  into  vari¬ 
ables.  In  general,  there  may  be  additional  rules  in  RL 
which  permit  the  assignment  of  other  types  of  objects 
to  v-objects.  If,  however,  r  is  the  only  such  rule,  then 
the  domain  of  a  v-object,  as  a  variable,  is  the  set  of  all 
0-objects.  We  will  call  such  a  variable  a  0-variable-,  we 
will  also  refer  to  it  as  a  simple  variable.  It  is  clear  that 
if  an  object  s  is  stored  in  a  simple  variable,  then  its 
brand  does  not  have  to  be  explicitly  stored.  Moreover 
if  all  the  variables  in  n  are  simple,  then  simple  applica¬ 
tion  rules  can  be  enforced  at  compile  time. 

These  properties  are  the  main  reason  why  many 
programming  languages  have  only  simple  variables,  e.g. 
integer  variables,  real  variables,  etc.  In  fact,  simple 
variables  are  so  common  that  one  tends  to  forget  the 
difference  between  the  type  (brand)  of  an  object  and 
the  domain  of  a  variable;  indeed  the  term  “type”  is 
usually  used  for  both,  although  it  is  clear  that  an 
“integer  number,”  for  example,  and  an  "integer  vari¬ 
able”  arc  not  similar  objects  and  do  not  satisfy  the 
same  rules. 
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Fig.  3.  An  illustration  of  the  proposed  approach  to  user-database 
interaction.  In  order  to  interact  with  the  database,  the  user  must 
first  effect  a  "connection"  between  a  language  L  and  a  subschema 
Z.  This  connection  generates  a  "new"  language  Lz.  The  user's 
program  would  operate  from  within  Lz,  so  to  speak.  It  has,  there¬ 
fore,  the  necessary  capabilities  to  interact  with  D/Z. 


In  the  rest  of  this  paper  we  will  assume,  first,  that 
the  user  program  is  written  in  a  language  whose  capa¬ 
bilities  can  be  described  as  above.8  This  means,  in  par¬ 
ticular,  that  the  application  rules  of  the  language  are 
Strictly  enforced  (such  languages  are  often  called 
“Strongly  typed”  languages).  Second,  we  want  these 
rules  to  be  explicit,  rather  than  implicit  in  the  overall 
structure  of  the  language.  This  second  property  will 
allow  us  to  augment  the  application  rules  of  the  lan¬ 
guage  by  the  rules  built  into  a  subschema  of  a  database, 
as  we  will  see  next. 


4.  A  Model  for  User-Database  Interaction 

We  have  already  seen,  in  Section  2,  that  in  order  to 
interact  with  an  image  D/2  of  a  database  D,  a  user  U 
must  first  be  connected  with  the  subschema  2,  which  in 
some  sense  contains  the  “capabilities”  necessary  for 
interaction  with  D/2.  Retaining  this  basic  notion  we 
will  now  give  it  a  new  interpretation.  We  begin  with  a 
general  outline  of  our  approach;  a  more  detailed  dis¬ 
cussion  will  follow. 

Let  L  be  the  programming  language  to  be  used  by 
U  for  his  interaction  with  the  database.  This  language 
might  have  some  special  tools  for  interaction  with 


*  This  docs  not  imply  that  every  user  should  use  such  a  language, 
hut  only  those  who  wish  to  take  advantage  of  intentional  resolu¬ 
tion  (see  Section  6). 

'  This  language  amplification  is  analogous  to  the  extension  of 
a  language  by  rjew  data  types  or  new  "clusters"  (1 1 1,  except  that 
here  the  extension  would  be  induced  into  the  program  from  the 
database,  and  not  defined  by  the  programmer  himself. 


databases,  such  as  the  DML  features  of  the  DBTG  [1], 
but  it  cannot  have  the  specific  capabilities  which  are 
necessary  for  the  interaction  with  a  given  image  D/Z. 
Presumably,  such  capabilities  exist  only  in  2.  In  order 
to  provide  our  user  with  these  capabilities,  we  will 
augment  the  capabilities  of  the  language  L  (in  the  sense 
of  Section  3),  by  the  capabilities  of  2.  This  action  will 
be  called  the  connection  between  L  and  2.  In  a  sense, 
such  connection  generates  a  new  "2-amplified”  lan¬ 
guage,  which  we  will  denote  by  Lz  .  This  “newly  created 
language,”  which  exists  only  for  the  duration  of  a 
single  session  of  interaction  between  U  and  D,  has  the 
same  syntax  and  most  of  the  semantics  of  the  “base 
language”  L.  It  is  an  amplified  language  only  in  the 
sense  that  it  contains  capabilities  which  do  not  exist  in 
L*  In  particular,  2  may  contain  new  brands  (types) 
and  new  rules  which  are  induced  into  the  newly  formed 
language.  Thus  a  program  written  in  Lz  will  be  under 
the  joint  jurisdiction  of  the  set  of  rules  built  into  L,  and 
those  in  2,  which  is  the  effect  we  are  trying  to  achieve. 
Figure  3  is  an  attempt  to  illustrate  this  model  of  user- 
database  interaction.  A  more  formal  treatment  of  this 
model  is  presented  below. 

4.1.  The  Subschema  and  Its  Connection  to  L 

The  subschema  will  be  viewed  here  essentially  as  a 
collection  of  capabilities  which  facilitate  interaction 
with  a  given  image  of  the  database,  and  which  are 
designed  to  augment  the  capabilities  of  a  given  language 
L.10  Formally,  2  is  defined  to  be  the  4-tuple  ( Sz  ,  Bz  ,  Pz  , 
Rz)  where: 

Sz  is  a  set  of  (names  of)  information  objects  in  D,  which 
are  to  be  accessible  to  the  user.  They  will  be  called 
D-objects  (e.g.  sets,  relations,  records  of  various 
types,  etc).  The  specification  of  the  brand  0  associ¬ 
ated  with  an  object  Q  £  Sz  will  be  done  by  the 
notation  “ Q :  P”. 

Rz  is  a  set  of  brands,  which  are  all  different11  from  the 
brands  in  Bl  - 

Pz  is  a  set  of  operators  (or  procedures)  which  are  de¬ 
fined  in  the  database,  and  which  the  user  is  allowed 
to  use.  These  operators  will  be  called  D-operators. 
Rz  is  a  set  of  application  rules,  to  be  called  D-rules, 
designed  to  regulate  the  interaction  of  a  user  pro¬ 
gram  with  the  database.  We  again  restrict  ourselves 
to  “simple  rules,”  which  have  the  following  general 
form: 

r:  0o  <=  ip,  Pt,  -  -  -,  P.)  (for  n  >  0) 

where  0*6  Bz  U  Bt  for  0  <  i  <  n,  and  Pz  U  PL  - 

This  is  exactly  the  structure  of  the  “simple  rules”  in 

'•This  does  not  mean  that  the  interaction  with  the  database 
must  be  carried  out  by  means  of  a  single  language.  Different  sub¬ 
schemas  may  be  designed  for  different  languages. 

"  To  distinguish  between  the  brands  in  -  from  those  in  L,  we 
will  denote  the  former  by  barred  lower  case  letters,  e.g.  a,&;  while 
the.  latter  are  denoted  by  barred  upper  case  symbols.  When  we  do 
not  wish  to  distinguish  between  Bz  and  Bl  we  will  use  PJiiJit .... 
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Jit,  except  that  these  rules  can  use  the  operators  and 
brands  in  2  as  well  as  those  in  L. 

This  concludes  the  formal  definition  of  the  sub¬ 
schema.  The  connection  of  -  with  L  can  now  be  viewed 
as  an  augmentation  of  the  capabilities  of  L,  namely  the 
sets  SL ,  Bl  ,  PL  ,  Rl  ,  with  the  corresponding  sets 
Sj ,  Bz  ,  Pz  ,  Rz  ■  This  augmentation  creates  the  2-am- 
plified  language  Lz  whose  capabilities  would  be 

(St  U  Si ,  Bl  U  flv ,  PL  U  Pz  ,  Rl  U  Rz). 

In  practice,  this  means  that  the  compiler  of  the 
language  L  should  be  able  to  accept  the  new  brands, 
rules,  etc.  which  are  defined  in  2,  and  it  should  enforce 
the  rules  Rz  U  R,.  on  the  user  program12  n. 

One  of  the  main  reasons  for  introducing  the  above 
model  was  to  give  the  database  a  degree  of  control  over 
what  happens  with  information  transmitted  to  the 
user’s  program.  Here  is  how  it  works.  Let  T  be  a 
Z?-operator,  and  let  r:  0  «=  {T, . . .)  be  a  rule  in  Rz  .  Let 
t «—  T(. . . .)  be  an  operation  authorized  by  r.  The  ob¬ 
ject  t  generated  by  T  (which  may  simply  be  a  piece  of 
.  data  retrieved  by  T  from  the  database)  would,  by  rule 
r,  be  branded  by  0.  To  see  what  the  future  of  t  might 
be,  we  will  distinguish  between  two  cases,  depending 
on  0. 

First,  if  0  is  a  member  of  BL  then  there  would  be 
rules  in  RL  which  specify  how  such  objects  can  be 
manipulated.  For  example,  if  &  is  7  then  this  object  can 
be  manipulated  like  any  other  integer  number.  In  gen¬ 
eral,  an  outcome  of  a  O-operation  w  hich  is  branded  by 
one  of  the  standard  brands  of  BL  is  released  from  the 
control  of  the  subschema  and  comes  under  the  juris¬ 
diction  of  the  language  L. 

Suppose  now  that  0  is  a  member  of  0z  ■  In  this  case 
there  is  no  rule  in  RL  which  authorizes  any  operation 
on  /.  The  only  operations  which  are  applicable  to  t  are 
those  which  are  authorized  by  rules  in  Rz .  Thus  al¬ 
though  the  object  t  resides  in  the  storage  space  of  the 
user’s  program,  it  is  still  under  the  jurisdiction  of  the 
database.  For  example,  the  program  would  not  be  able 
to  multiply,  compare,  or  print  the  object  /  unless  such 
operations  are  permitted  by  Rz. 

Before  considering  an  example,  we  will  introduce 
some  conventions  and  notation  which  will  simplify  the 
subsequent  discussion. 

(a)  For  every  brand  0  explicitly  included  in  Bz  ,  we 
assume  that  there  is  a  companion  brand  in  Bz  which  is 
the  brand  of  0-variables  (see  Section  3.2).  That  is,  a 
program  written  in  Lz  should  be  able  to  generate  { or 
declare )  0-variables  for  every  brand  0  explicitly  included 
in  Bz  in  much  the  same  way  that  “integer  variables’’ 
are  declared  in  Algol. 

(b)  Because  it  is  sometimes  necessary  to  generate  a 
copy  of  an  object,  assigning  a  different  brand  to  it,  we 

*  Whenever  there  is  no  danger  of  confusion  we  will  not  dis¬ 
tinguish  between  the  user's  program  and  the  process  oj  computation 
generated  by  it;  both  will  be  denoted  by  it. 


introduce  a  special  operator,  called  CONVERT,  which 
does  just  that.  For  example,  if  we  have  the  rule 
0t  «=  ( CONVERT ,  0i)  it  means  that  the  operation 
Si  «—  CONVERT(si)  can  be  invoked  for  any  di-objcct 
Si ,  generating  an  object  *■.  such  that  brand(s;)  =  0-  and 
valueis.)  =  value! si).  The  operator  CONVERT  is 
assumed  to  be  included  in  PL  . 

(c)  We  assume  that  there  is  a  universal  retrieval 
operator  GET,  which  retrieves  an  arbitrary  member  of 
any  set  in  the  database.  GET  will  be  assumed  to  exist 
in  every  Pz ,  but  its  application  to  a  given  set,  and  the 
brand  of  its  outcome,  must  be  explicitly  specified  by 
rules  in  Rz  ■  (Similar  assumptions  are  made  concerning 
a  universal  storage  operator  PUT.) 

4.2.  An  Example 

To  clarify  all  this,  let  us  return  to  the  binary  tree 
example  of  Section  2.  Consider  the  following  sub¬ 
schema: 

2  =  \Sz,  Bz,  Pz,  Rz\, 

Sz  =  \N:n\,  Bz  =  |n|, 

Pz  =  [f-SON,  RSON,  DATA  [ , 

Rz  *=  {rl :  n  <=  ( LSON ,  h) 
rl-.  n  <=  {RSON,  ft) 
r3:  /  «=  {DATA,  rl)}. 

First,  note  that  there  is  a  brand  it,  defined  in  2,  which 
would  therefore  be  induced  as  a  brand  (or  type,  if  you 
will)  of  the  language  Lz  .  By  convention  (a)  this  means 
that  a  program  n  written  in  Lz  can  generate  (or  de¬ 
clare)  n-variables,  namely,  variables  which  can  contain 
only  h -objects.  We  need  to  ask  how  n -objects  can  be 
generated,  and  how  the.  can  be  manipulated. 

One  n-object  is  the  rode  N  which  is  declared  in  Si 
to  be  7t-branded.  In  addition,  the  subschema  provides 
II  with  the  operators  LSON  and  RSON,  which,  by 
rules  rl  and  rl,  can  generate  n-objects.  Note  that  these 
are  the  only  ways  to  generate  n-objects.  Even  if  II 
manages  to  get  a  node  n  £  tree{N)  from  an  outside 
source,  it  cannot  make  it  into  an  n-object.  Moreover, 
once  an  n-object  is  created  it  cannot  be  modified  in  any 
way;  there  simply  is  no  rule  which  permits  that. 

Now,  since  n-objects  are  the  only  type  of  objects 
which  can  be  used  as  an  argument  for  any  of  the  oper¬ 
ators  LSON,  RSON,  and  DATA,  it  is  clear  that  an 
n-object  belongs  to  tree{N).  (Note  the  correspondence 
with  the  two  rules  formulated  in  Section  2  for  this 
example.)  Moreover,  if  ri-objects  are  stored  only  in 
7'1-variubles,  then  all  these  rules  can  be  enforced  at 
compile  time. 

Note  that  the  only  "printable”  information  that  the 
user  can  get  from  all  this  is  the  outcome  of  the  operator 
DATA,  which  is  /-branded  and  is,  therefore,  a  "normal 
integer.”  (It  is  assumed  here  that  every  node  in  our  tree 
contains  a  single  integer  value  us  its  data  part.) 

As  a  further  illustration,  let  us  consider  a  small  vari¬ 
ation  of  the  above.  Suppose  that  for  some  reason  the 
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user  is  interested  in  examining  the  n  objects  themselves. 
We  can  easily  permit  that  without  compromising  our 
security  requirements.  Suppose  that  an  ft -object  is 
actually  an  integer  number,  which  would  be  the  case 
if  it  is  some  sort  of  pointer  to  a  node.  We  can  add  to 
Rz  the  rule 

r4:  /  «=  {CONVERT,  ft) 

using  the  standard  operator  COPY  introduced  by  con¬ 
vention  (b)  above.  In  effect,  r4  allows  IT  to  copy  the 
value  of  any  u-object  into  an  integer  variable,  but  it 
does  not  allow  n  to  change  the  n-object  itself. 


5.  Techniques  for  Intentional  Resolution  in 
Privacy  Protection 

In  this  section  we  will  discuss  several  types  of  pro¬ 
tection  problems,  and  their  proposed  solution.  What  is 
common  to  all  these  problems  is  that  they  cannot  be 
solved  by  access  control  alone;  or,  at  best,  their  access 
control  solution  is  very  difficult. 

5.1.  Preventing  Undesirable  Analysis  of  Data 

The  power  of  the  database  as  a  source  of  informa¬ 
tion  is  due  not  only  to  the  fact  that  there  is  a  great  deal 
of  data  stored  in  it  which  can  be  retrieved,  but  also  to 
the  ability  to  correlate  various  pieces  of  data  with  each 
otner.  This  ability,  which  sometimes  carries  very  sensi¬ 
tive  information,  can  be  denied  to  a  user,  as  is  illus¬ 
trated  by  the  following  example. 

Let  D  be  a  database  maintained  by  a  credit  bureau, 
and  let  E  =  le|  be  a  set  of  records  about  financial 
transactions.  Let  the  structure  of  such  a  record  be 
e  =  (pname,  trans,  company)  where  pname  is  the  name 
of  the  person  involved;  trans  is  the  description  of  the 
transaction,  and  company  is  the  name  of  the  company 
involved.  The  main  security  problem  in  such  databases 
is,  of  course,  the  individual  privacy  of  the  people; 
However,  here  we  will  consider  this  problem  solved 
and  deal  with  the  privacy  of  the  companies  involved. 

The  problem  is  this:  although  the  credit  database  is 
intended  to  provide  information  about  people,  it  can 
be  used  for  the  analysis  of  the  financial  state  of  a  com¬ 
pany.  Such  analysis  can  usually  be  performed  by  any 
program  which  has  access  to  the  entire  set  £,  simply  by 
collecting  all  available  information  about  a  given  com¬ 
pany.  To  prevent  a  user  from  doing  this  kind  of  analysis 
we  will  connect  him  to  the  following  subschema  : 

X  -(Sz,Bz,Pz,  Rz), 

Ss  -  (£:e),  Bz  =  [e,  t,  <*,/}, 

ft  -  [PNAME,  TRANS,  COMPANY,  GET], 

Rz  m  {rl:  f  «s  (GET,  e) 

r2:  T  «=  (PNAME,  r) 
r3:  T  <=  (TRANS,  f) 
r4:  C  «-  (COMPANY,  f) 
r5:  (PRINT,  C,J)  |. 

m 


Rule  rl  in  Rz  is  intended  to  mean  that  every  record 
retrieved  from  E  would  be  f-branded  (GET,  being  a 
general  purpose  retrieval  operator.)  By  rules  r2,  r3,  and 
r4,  the  three  given  D-opcrators  can  be  applied  to  such  a 
record,  returning  its  three  components.  The  outcome 
of  the  first  two  operators  is  T-branded;  namely,  it 
would  be.  treated  as  a  normal  text  and  can  be  freely 
manipulated  by  IT.  However,  by  rule  r4,  the  company 
component  would  be  c-branded  and  therefore  is  not 
released  from  the  control  of  22.  Rule  r5  is  intended  to 
mean  that  c-branded  data  can  be  printed  on  /-branded 
files,  which  would  presumably  contain  the  desired 
output  of  the  program,  and  would  be  routed  to  appro¬ 
priate  officials.  Thus  the  names  of  the  companies  in¬ 
volved  can  be  printed  on  the  final  document,  but  they 
cannot  serve  as  a  basis  for  any  analysis  by  the  program 
which  produces  this  document. 

5.2  Hiding  Intermediate  Results  of  Computations 

Consider  a  user  who  is  allowed  to  get  certain  statis¬ 
tical  information  from  a  database,  but  is  not  allowed 
to  see  the  raw  data.  Suppose  that  the  statistical  infor¬ 
mation  can  be  produced  by  a  procedure  built  into  the 
database,  assuming  that  this  procedure  does  not  reveal 
any  confidential  information  to  its  users.  The  question 
is,  how  do  we  prevent  the  user  from  printing  out  the 
raw  data  which  he  feeds  to  the  statistical  procedure, 
particularly  if  the  user  has  to  select  the  data  himself. 
This  is  an  example  of  a  more  general  situation  where 
the  user  is  allowed  to  get  the  final  result  of  a  sequence 
of  computations  performed  in  the  context  of  a  database, 
but  he  is  not  allowed  to  see  the  raw  data  or  the  interme¬ 
diate  results.  In  order  to  show  that  access  control  tech¬ 
niques  may  not  be  sufficient  for  such  a  situation  we 
will  analyze  in  detail  a  sequence  of  related  privacy 
measures,  of  increasing  complexity,  for  a  fairly  general 
class  of  problems. 

Let  E0  be  a  set  of  records  in  the  database  D,  and  let 
7~i , . . . ,  Tk  be  D-operators.  For  a  given  e0  6  £0 ,  let 
et . e*  be  defined  by  the  following  equations: 

e\  =  Tie o  ;  e2  =  7Vi  ;  .  . .  ;  e*  =  7*e*_j 

and  let  £<  be  the  set  of  all  such  e<  for  1  <  f  <  Ic. 

First,  suppose  that  U  is  allowed  to  see  £*  but  is  not 
allowed  to  see  the  intermediate  results  E,  (i  <  k)  or 
the  raw  data  £)  .  This  privacy  measure  can  easily  be 
enforced  by  means  of  standard  access  control  tech¬ 
niques,  provided  that  U  can  define  E0  to  the  database 
without  actually  examining  it.  All  we  have  to  do  is  to 
permit  the  user  to  apply  the  composite  operator 

t  -  i* . . .  •  Tt 

to  Et . 

Suppose  next  that  every  one  of  the  records  c,  is  a 
pair:  e,  =  (a,  ,  b,),  and  that  the  user  is  allowed  to 
examine  a, ,  but  not  b, ,  for  i  <  k.  (The  situation  is 
illustrated  in  Figure  4,  where  the  wavy  arrows  indicate 
which  information  should  be  released  to  n,  and  double 
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Fig.  4.  Hiding  intermediate  results. 


arrows  indicate  information,  including  operators,  de¬ 
rived  directly  from  the  database.) 

The  situation  now  is  more  complicated  because  the 
user  might  want  to  use  his  right  to  inspect  a,  in  order 
to  select  members  of  E„  and  to  decide  whether  or  not 
to  continue  with  a  particular  sequence  of  transforma¬ 
tions.  It  is  not  possible  anymore  to  replace  the  indi¬ 
vidual  transformations  T,  by  the  composite  transfor¬ 
mation  T,  because  the  latter  does  not  provide  for  any 
user  intervention.  The  user’s  program  itself  should  be 
able  to  generate  the  partially  confidential  records  e, . 
Moreover,  an  arbitrary  number  of  e,’s  may  be  gener¬ 
ated  and  maintained  by  II  at  any  given  time.  Since  these 
records  are  not  part  of  D  proper,  it  seems  that  they 
belong  to  the  storage  space  of  II.  Therefore  to  maintain 
their  secrecy  n  must  be  restricted  as  to  what  it  can  do 
with  these  records.  And  yet,  the  situation  can  still  be 
handled  by  means  of  access  control,  even  if  very  in¬ 
efficiently,  as  follows: 

Suppose  that,  when  a  record  e,  is  generated  by  T,  it 
is  stored  somewhere  in  the  database  (although  it  does 
not  logically  belong  there).  Only  the  nonsecret  compo¬ 
nent  a.  of  e,  is  actually  transmitted  to  n,  together  with 
a  pointer  to  e, ,  to  be  denoted  by  p, .  When  n  applies 
the  operator  T,± i  to  the  pair  (a,  ,  p,),  the  database  will 
use  pi  to  locate  the  complete  record  e, .  Since  the  pointer 
p,  does  not  carry  any  meaningful  information  for  the 
user,  it  can  be  safely  released  to  his  program.  Thus, 
although  it  would  be  very  difficult  and  inefficient,  it  is 
still  possible  (at  least  in  principle)  to  enforce  the  privacy 
restrictions  at  hand  with  access  control  alone. 

As  a  final  version  of  our  privacy  measures  we  will 
now  consider  the  following  situation:  Suppose  that 
although  the  value  of  the  components  ft ,  of  e,  should 
not  be  released  to  the  user,  he  is  allowed  to  manipulate 
these  components  in  various  ways.  For  example,  the 
user’s  program  might  be  allowed  to  print  the  entire 
record  e,  ,  including  ft,  ,  on  a  certain  file;  (assuming 
that  this  file  would  be  physically  unavailable  to  the 
user).  Or  he  might  be  allowed  to  compare  the  various 
6,'s  with  each  other,  but  not  with  anything  else.  (This 
capability  might  reveal  to  the  user  certain  limited 
amounts  of  information  about  ft,.)  Now,  since  IT  is 
allowed  to  perform  certain  ''normal1’  operations  with 


the  records  e,  using  the  primitive  operators  of  the 
language  L,  it  is  clear  that  e,  must  be  stored  in  the 
storage  space  of  II.  Since  the  secrecy  of  the  component 
ft,  of  e,  must  still  be  protected,  we  must  be  able  to 
impose  restrictions  on  n.  Thus  access  control  is,  in 
principle,  not  powerful  enough  for  such  a  case.  The  way 
to  handle  this  problem  by  means  of  our  techniques  is 
left  for  the  reader. 

5.3.  The  Need  for  Local  Confinement 

We  now  will  consider  a  class  of  problems  for  which 
the  protection  techniques  of  Section  4  are  not  sufficient 
and  would  have  to  be  refined.  We  will  begin  with  a 
very  simple  example. 

Consider  a  database  D  and  a  highly  confidential  set 
of  records  F  in  it.  Let  U  be  a  programmer  who  is  com¬ 
missioned  to  program  and  apply  a  transformation  T  to 
every  record/ £  F  and  to  store  the  transformed  records 
back  into  the  database  as  a  set  F' .  Suppose  that  due  to 
the  confidentiality  of  F  we  do  not  want  its  content  to 
be  revealed  to  the  programmer  U  himself,  or  to  be 
leaked  in  any  form  or  shape  to  the  outside  world.  (This 
is  an  example  of  the  class  of  problems  mentioned  in 
the  Introduction.  As  was  pointed  out  there,  the  solu¬ 
tion  of  this  kind  of  problem  has  great  practical  im¬ 
portance.) 

The  difficulty  with  this  case  is  that  since  our  user 
has  to  program  the  transformation  T  himself,  the  con¬ 
fidential  records  /  £  F  must  be  released  to  his  program 
so  that  they  can  be  examined  and  manipulated.  This 
means,  however,  that  the  records  retrieved  from  F 
would  not  be  under  the  jurisdiction  of  the  ZJ-rules,  and 
we  are  back  where  we  sorted. 

One  solution  to  our  Problem  is  to  confine  the  user’s 
program,  in  the  sense  of  Lampson  [7],  namely,  to  block 
all  the  “output  channels”  of  II  so  that  it  cannot  com¬ 
municate  to  the  outside  world  any  information  about 
F  while  it  is  still  allowed  to  write  into  F'.  However, 
such  a  complete  confinement  of  the  user’s  program  may 
not  be  desirable  because  the  same  program  which 
manipulates  the  confidential  information  may  also  be 
doing  other  things  which  might  require  various  output 
channels.  Thus  instead  of  the  confinement  of  the  entire 
program  n,  we  would  prefer  a  "local  confinement” 
only  of  those  parts  of  II  which  need  a  free  access  to  F. 
For  this  we  introduce  a  new  linguistic  construct  to  be 
called  the  confidence  module. 

5.3.1.  Confidence  modules.  Let  M  be  a  module 13  of  a 
program  n,  such  as  an  Algol  block  or  procedure.  The 
storage  space  of  n  can  be  divided  into  two  mutually 
exclusive  parts  with  respect  to  M :  the  internal  storage 
space  of  M,  which  is  accessible  only  from  within  M, 
and  the  environment  of  M,  to  be  denoted  by  £(M), 
which  is  all  the  rest.  E(M)  would  include  not  only 
variables  defined  within  IT,  but  also  files  and  those  parts 

”  The  concept  of  ‘'module,"  as  well  as  some  other  standard 
concepts  to  be  mentioned  below,  wilt  not  be  defined  here. 
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of  the  database  which  arc  accessible  to  IT.  Normally  a 
module  has  a  variety  of  means  by  which  it  can  affect 
its  environment  and  thus  pass  information  to  it.  For 
example,  M  may  change  a  variable  which  is  in  its 
scope  but  is  not  internal  to  it;. it  may  write  on  a  file, 
etc.  Informally  we  will  refer  to  all  such  means  that  M 
has  to  affect  its  environment,  as  the  output  channels  of 
Af.  (Note  that  even  the  existence  of  multiple  exit  points 
out  of  the  module  should  be  considered  as  an  output 
channel.)  Usually  one  does  not  have  much  control  over 
which  output  channels  a  given  module  will  have.  For 
example,  if  a  file  is  accessible  to  a  program  it  is  usually 
accessible  to  all  its  modules.  This  brings  us  to  the  fol¬ 
lowing  concept. 

Definition.  A  confidence  module  is  a  module  which 
has  only  a  specified  set  of  available  output  channels. 

We  will  no£say  how  exactly  output  channels  should 
be  specified,  but  an  example  might  clarify  the  concept. 
Let  F  be  a  file  name,  and  let  b  be  a  brand;  then 

confidence(F,b)  begin... end 

would  be  a  module  whose  output  channels  consist  of 
the  file  F  and  any  6-branded  variable  that  this  module 
can  access. 

Note  that  there  are  no  restrictions  on  what  a  confi¬ 
dence  module  can  “see,”  since  we  are  concerned  only 
with  how  a  module  can  communicate  information  to 
its  environment.  Thus,  for  the  purpose  of  read-only 
access,  a  confidence  module  may  have  the  normal  scope 
of  an  Algol  block,  say. 

A  systematic  study  of  the  concept  of  confidence 
modules  and  their  implementation  is  outside  the  scope 
of  this  paper.  The  interested  reader  is  advised  to  study 
Lampson’s  paper  [7],  which  discusses  the  problems  in¬ 
volved  in  the  confinement  of  programs.  (It  should  be 
pointed  out,  however,  that  Lampson’s  paper  is  con¬ 
cerned  primarily  with  the  operating  system  aspects 
of  confinement.  Here,  on  the  other  hand,  since  we 
are  talking  about  a  linguistic  construct,  the  compiler 
should  carry  the  main  responsibility  for  enforcing 
confinement.) 

5.3.2.  Use  of  confidence  modules.  In  order  to  use  the 
confidence  modules  for  intentional  resolution  we  will 
have  to  generalize  our  application  rules.  As  was  already 
pointed  out,  the  scope  of  a  simple  rule,  introduced  in 
Section  3,  is  the  entire  program  II.  That  is,  operations 
which  are  legalized  by  a  certain  rule  r  can  be  carried 
out  anywhere  within  IT.  We  now  introduce  a  restric¬ 
tion  of  the  scope  of  an  application  rule  to  a  certain 
type  of  confidence  modules,  as  follows: 

Let  r  be  an  application  rule;  then  the  rule 

r:  rf  confidence^,, . . .,  c.) 

is  identical  to  r  but  is  valid  only  within  confidence 
modules  which  do  not  have  any  output  channels  except 
c» , . . . ,  c, .  (It  is  assumed  here  that  c,  denote  “output 
channels”.)  The  usefulness  of  this  generalization  comes 


simply  from  the  fact  that  one  might  he  willing  to  let  the 
user  program  see  more  of  the  database,  hut  within  a  con¬ 
fidence  module  from  which  he  cannot  communicate  freely. 
This  is  readily  demonstrated  by  the  following  treatment 
of  the  example  which  was  given  at  the  beginning  of 
Section  5.3. 

Consider  the  subschema  defined  by: 

-  “  \Sz,B:,P:,  Rz\, 

S'-  =  i F-  I,  F ':  /),  Bz  =  Jfi,,  6,,  /,/'}, 

Pz  =  [GET,  PUT\, 

Rz  =  \r\ :  &i  «=  {GET,}) 

rl:  1  <=  {CONVERT,  In)  confidence (5.) 
r3:  fc  <=  ( CONVERT ,  1) 
r4:  (PUT,  b„ I'll- 

The  program  n  written  in  L  would  be  allowed,  by 
rule  rl,  to  invoke  the  Z>-function  GET(F),  which  is 
assumed  to  produce  a  record  f  t  F  as  its  outcome; 
every  such  record  would  be  6i-branded.  The  brand  6i 
appears  only  in  one  more  rule,  in  r2,  which  permits  the 
conversion  of  a  6, -object  into  an  integer,  where  for 
simplicity  it  is  assumed  that  F  is  a  set  of  integer  num¬ 
bers.  Note,  however,  that  r2  is  applicable  only  within 
confidence  modules  whose  only  output  channels  are 
Si-branded  variables.  Outside  such  a  confidence  mod¬ 
ule14  the  records /  €  F  cannot  be  manipulated  or  exam¬ 
ined.  Let  M  be  such  a  module  (see  Figure  5).  Since  M 
is  able  to  transform  any  /  to  an  integer,  it  is  possible 
to  program  an  arbitrary  transformation  T(f)  in  M.  At 
the  same  time,  M,  being  a  confidence  module,  cannot 
affect  its  environment  except  by  writing  into  S-branded 
variables.  By  r3,  any  integer  number  can  be  converted 
into  a  (^-object.  A  ^-branded  object,  in  turn,  can  only 
be  written  in  F',  according  to  r4.  No  other  operation 
can  be  applied  to  it. 

It  is  dear  that  our  privacy  requirements  are  fully 
satisfied.  The  programmer  can  carry  out  an  arbitrary 
transformation  on  F,  storing  the  results  of  his  trans¬ 
formation  in  F',  but  he  has  absolutely  no  way  to  see 
the  file  F1  itself  or  any  information  about  it,  or  to  leak 
such  information  to  anybody  else.  At  the  same  time 
the  program  as  a  whole  is  not  confined  or  limited  in 
any  sense.  (The  reader  may  wonder  why  the  brand  6.  is 
necessary;  is  it  not  simpler  for  the  module  M  itself  to 
write  /  on  F'l  This  is  indeed  the  case  for  the  problem 
at  hand.  However,  b,  would  be  necessary  in  the  slightly 
more  general  case  where  the  user  is  allowed  to  apply 
certain  Z>-operators  to  f',  which  he  might  want  to  do 
outside  of  M.) 


6.  Scope  of  Application  of  Proposed  Technique 

A  major  disadvantage  of  the  method  for  user-data- 
base  interaction  introduced  in  Section  4  is  the  strong 
requirements  imposed  by  it  oq  the  language  in  which 

14  Note  that  the  user  can  have  any  number  of  confidence 
modules  in  his  program. 
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Fij.  5.  The  situation  created  by  the  subschema  2  described  in 
Section  5.3.2.  I  he  records  /  ■_  F  which  are  retrieved  by  11  are 
enclosed  in  an  opaque  box  in  which  shields  them  from  II.  (The  box 
represents  the  brand  in).  The  only  way  out  of  this  box  leads  into  a 
confidence  module,  which  in  turn  has  only  one  output  channel 
which  leads  into  another  coniinement,  the  box  />,.  Within  the  con¬ 
fidence  module  M,  the  records  /  •  Fean  be  manipulated  freely  so 
that  an  arbitrary  transformation  T can  be  performed  on  them.  The 
single  arrows  labeled  tnp  illustrate  the  fact  that  there  is  no  restric¬ 
tion  on  input  channels  to  a  confidence  module.  The  labels 
rl  . .  r4  on  the  double  arrows  represent  the  £>-rule  which  legal- 
ias  the  transmission  of  information  represented  by  the  arrow. 


the  user  program  is  written.  For  example,  neither  Cobol 
nor  Fortran  can  be  used  for  this  kind  of  interaction, 
and  certainly  not  an  assembly  language.  An  appropriate 
“strongly  typed”  language  can  and  should  be  designed, 
but  it  would  be  unrealistic  to  assume  that  the  average 
user  would  be  willing  to  give  up  his  favorite  language 
in  order  to  interact  with  a  database.  Indeed,  this  is 
not  our  intention.  Our  method  for  user-database  inter¬ 
action  is  intended  for  the  hopefully  few  cases  in  which 
intentional  resolution  is  necessary.  In  this  section  we 
will  try  to  identify  some  of  these  cases. 

First,  it  should  be  pointed  out  that  the  term  "user- 
database  interaction”  does  not  reflect  correctly  the  way 
in  which  databases  are  used  in  general.  In  practice,  the 
entity  which  interacts  directly  with  a  database  is  often 
some  general  purpose  "application  program,”  which 
in  turn  serves  a  number  of  "end-users."  In  such  a  case 
it  may  be  sufficient  to  control  the  interaction  between 
the  application  program  and  the  database  so  that  the 
program  cannot  reveal  to  its  user  any  confidential  in¬ 
formation,  even  it  it  can  get  it  from  the  database.  If  it 
is  not  necessary  to  control  the  interaction  between  the 
end-users  and  the  application  program,  then  the  end- 
users  can  use  an  arbitrary  programming  language.  The 


only  requirement  would  be  that  the  application  pro¬ 
gram  is  written  in  a  language  of  the  type  of  Section  3. 
Since  such  an  application  program  is  typically  designed 
as  an  integral  part  of  the  information  management 
system  at  hand,  this  does  not  seem  to  be  an  unreason¬ 
able  requirement.  It  is  quite  common  for  an  installation 
to  impose  restrictions  on  the  language  and  style  of 
programming  which  is  used  for  its  major  systems. 

There  is  another  class  of  programs  whose  interac¬ 
tion  with  the  database  should  be  controlled  by  the 
techniques  introduced  in  this  paper.  These  are  the  pro¬ 
cedures  built  into  the  database  itself.  Indeed  it  is  a  well- 
known  principle  of  design  of  large  systems  that  the 
interaction  between  every  module  of  the  system  and 
the  rest  of  it  should  be  carefully  controlled.  We  believe 
that  this  control  should  include  intentional  resolution. 
In  this  case  intentional  resolution  can  be  achieved  if 
the  entire  database  is  programmed  in  a  single  strongly 
typed  language.  This  aspect  of  database  design  is  dis¬ 
cussed  in  f 8], 

Finally,  it  should  be  pointed  out  that  the  protection 
technique  proposed  in  this  paper  is  applicable  not  only 
for  intentional  resolution.  It  was  shown  in  [10]  that 
several  other  protection  problems  can  be  solved  more 
efficiently  by  imposing  control  over  the  user  programs 
than  just  by  means  of  access  control.  Our  binary  tree 
example  (Section  4)  is  one  such  problem. 

7.  Conclusion 

The  main  thrust  of  this  paper  has  been  the  intro¬ 
duction  of  intentional  rr  o/ution  as  an  independent  di¬ 
mension  of  privacy  prot  ;iion,  which  is  complimentary 
to  access  control.  This  aspect  of  privacy  protection  is 
either  totally  ignored  in  the  database  literature,  or  at 
best  it  is  listed  as  one  of  the  unsolved  problems  [9], 
leaving  a  wide  gap  in  our  ability  to  protect  the  privacy 
of  data.  In  particular,  under  most  database  systems 
the  programmers  who  maintain  an  information  system 
have  a  virtually  unrestricted  access  to  all  the  informa¬ 
tion  in  it.  This  paper  is  intended  to  suggest  an  approach 
for  dealing  with  these  kinds  of  protection  problems, 
but  it  does  not  present  a  complete  solution.  This 
work  should  be  completed  and  generalized  in  a  num¬ 
ber  of  directions;  the  following  two  are  particularly 
important: 

(a)  The  “simple  application  rules”  are  much  too  simple 
and  should  be  generalized. 

(b)  The  problem  of  how  subschemas  are  generated 
and  maintained  in  the  database  was  not  addressed  at 
all  in  this  paper.  This  problem  can  be  treated  only 
in  the  context  of  a  comprehensive  study  of  the  struc¬ 
ture  of  database  systems  and  is  therefore  beyond  the 
scope  of  this  paper. 
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In  this  issue  the  calendar  is  given  to  January 
19 77.  Sew  listings  are  given  first,  and  they  are 
not  repeated  in  the  second  part. 


NEW  LISTINGS 
7-9  April  1976 

Second  Annual  Government-Industry  ADP 
Conference:  Federal  Government  Data  Systems, 
1976-1916,  Sheraton  Beltway  Convention  Center. 
Washington.  D.C.  Sponsors:  AUE  in  coop,  with 
Federal  Departments  and  Independent  Agencies 
in  the  Washington.  D.C.  area.  Contact:  Dept. 
PR,  AUE  Seminars.  P.O.  Box  25i16,  Los  Ange¬ 
les,  CA  90025;  213  826-7572. 

17- 19  May  1976 

Canadian  Computer  Conference  —  Sesrion 
76,  Queen  Eli;abeth  Hotel.  Montreal.  Canada. 
Sponsors:  CIPS  and  CSA.  Contact:  J.H.M. 
William;.  Canadian  National.  Management  Serv¬ 
ices,  Box  8100  Montreal.  Quebec.  Canada. 

18- 19  October  1976 

■  Fifth  Texas  Conference  on  Computing  Sys¬ 
tems*  Thompson  Conterence  Center.  Austin, 
Texas.  Sponsors:  The  University  of  Texas  in 
coop,  with  ACM  and  IEEE-CS.  Contact:  James 
Sneetlnger.  Dep.  of  Computer  Sciences.  Painter 
Hall  3.z8.  The  University  of  Texas.  Austin.  TX 
787*2. 

29  November-!  December  1976 

■  Bicentennial  Conference  on  Mathematical 

Programming.  NBS.  Gaithersburg.  Md.  Spon¬ 
sors:  ACM  SIGMAP  and  NBS  Applied  Mathe¬ 
matics  Division.  Conf.  chm:  Harvey  J.  Green¬ 
berg.  VPI  and  ML  11440  Isaac  Newton  Square, 
Reston.  VA  22090. 

6-8  December  1976 

■  Winter  Simulation  Conference.  NBS.  Gaith¬ 
ersburg.  Maryland.  Sponsors-  AC'M  SIGSIM  and 
NBS.  Chm:  Harold  Highland,  Computer  Science 
Department,  New  York  State  Technical  College, 
Farmingdale,  NY  11735;  5*6  420-2190. 


PREVIOUS  LISTINGS 
17-19  March  1976 

■  Ninth  Annual  Simulation  Sympuslam, 
Tampa,  Ra.  Sponsor:  Society  for  Computer  Sim¬ 
ulation  <SCS)  with  the  cooperation  of  ACM  and 
IEEE-CS.  Contact:  L.  Ed  Gets,  Director.  Corpo¬ 
rate  Planning,  Green  Giant  Company,  Hazeltine 
Gates,  Chaska.  MN  55555;  612  448-2828. 

22-24  March  1976 

•  Conference  on  Data:  Abstraction,  Defini¬ 
tion,  nod  Structure,  Salt  Lake  City.  Utah.  Spon¬ 
sors:  ACM  SIGPLAN  and  SIGMOD.  Chin:  El¬ 
liott  !.  Organick.  Department  of  Computer  Sci¬ 
ence.  Room  3160  Merrill  Engineering  Building. 
Salt  Lake  City,  UT  84112. 

29-31  March  1976 

■  International  Symposium  on  Computer  Mod¬ 
eling,  Measurement,  and  Evaluation,  Cambridge, 
Mass.  Sponsors:  ACM  SIGMETRICS  and  IF1P 
Working  Group  7.3  (Computer  System  Modeling). 
Co-chm:  J.  P.  Buzen.  Aiken  Computation  Lab.. 
Harvard  University.  Cambridge,  MA  02138;  and 
Arnold  Ockenc,  IBM  World  Trade  E/ME/A 
Corp..  One  North  Broadway  (WPPN-5;  Dept. 
465).  White  Plains.  NY  10601. 

30  March  1976 

■  Fortran  Forum  III,  Washington.  D.C.  Spon¬ 
sor:  ACM  SIGPLAN.  Chm:  Frank  Engel  Jr  179 
Lewis  Road.  Belmont,  MA  02175;  617  484-5911. 

31  March-2  April  1976 

Conference  on  Information  Sciences  and 
Systems,  The  Johns  Hopkins  University,  Balti¬ 
more.  MO.  Contact:  G-CL.  Meyer  or  W.J.  Rugh. 
1976  Cl  0  Electrical  Engineering  Dept..  The 
Johns  Hopkins  University.  Baltimore,  MD  21218. 
31  March-2  April  1976 

ORSA/TIMS  1976  Joint  National  Meeting. 

Sheraton  Hotel.  Philadelphia,  Pa.  Contact:  J.J. 
Burbridge.  Publicity  Chairman,  1976  Joint  ORSA/ 
TIMS  Meeting,  College  of  Engineering,  Rutgers 
University,  New  Brunswick,  NJ  08903. 

1-2  April  1976 

■  Computer  Science  and  Statistics:  Ninth  An¬ 
imal  Symposium  on  the  Interface,  Harvard  Uni¬ 
versity,  Cambridge.  Mass.  Sponsors:  ASA  and 
Harvard  U.  in  coop,  with  ACM.  Contact:  David 
C.  Hoaglin.  Dep.  of  Statistics.  Harvard  Univer¬ 
sity,  1  Oxford  St.,  Cambridge,  MA  02138. 

1-2  April  1976 

■  Third  ICASE  Conference  on  Scientific  Com¬ 
puting:  Computer  Science  and  Scientific  Com¬ 
puting,  Quality  Inn  Fort  Magmder,  Williams¬ 
burg,  VA.  Sponsor:  ICASE  in  cooperation  with 
ACM,  ACS,  AIAA.  ASCE.  IEEE.  SIAM.  Prog, 
chm:  James  M.  Ortega.  ICASE.  Contact:  Robert 
G.  Voigt.  ICASE.  MS-132-C.  NASA  Langley  Re¬ 
search  Center,  Hampton.  VA  23665;  804  827-2513. 


Symposium  on  Recent  Resol ts  and  New  Di¬ 
rections  in  Algorithms  and  Complexity,  Carnegie- 
Mellon  University.  Pittsburgh,  Pa.  Contact:  J.F. 
Traub.  Computer  Science  Dep.,  Camegie-McHon 
U..  Pittsburgh.  PA  15213. 


8-9  April  1976 

g  Computer  Management  Symposium.  Mar¬ 
riott  Hotel,  St.  Louis,  Mo.  Sponsor:  ACM  SIG- 
UCC.  Contact:  Ralph  E.  Lee.  University  of  Mis- 
souri-Rolla.  Computer  Center,  Rolla.  MO  65401; 
314  341-4841. 

13-13  April  1976 

2nd  International  Symposium  on  Program- 
mint,  Paris,  France.  Organized  by  The  Instltut 
de  Progr animation.  Sponsors:  Centre  National  de 
la  Recherche  (CNRS)  and  Universite  Pierre  et 
Marie  Curie.  Contact:  Secretariat  Uu  Collocate. 
Institut  de  Programme! ion.  4.  Place  Jussieu.  75230 
Paris  Cedex  05.  France;  Tel.  325.12.21  x53.97. 


20  22  April  1976 

MRI  Symposium  on  Computer  Software 
F.ngineering,  Barbi/on  P!a/,a  Hotel.  New  York. 
N.Y.  Sponsors:  polytechnic  Institute  of  New 
York.  Air  Force  Office  of  Scientific  Research. 


Army  Research  Office,  and  Office  of  Naval  Re¬ 
search  in  coop,  with  ACM.  IEEE-CS.  and  IEEE 
Professional  Group  on  Reliability.  Contact: 
Jerome  Fox,  Polytechnic  Institute  of  New  York, 
MRI  Symposium  Committee,  333  Jay  Street, 
Brooklyn.  NY  11201. 

20-23  April  1976 

Third  European  Meeting  on  Cybernetics 
and  Systems  Research  (EMCSR  76).  Vienna. 
Austria.  Sponsor:  Austrian  Society  for  Cyber¬ 
netic  Studies.  Chm:  Robert  Trappl.  Osterreichts- 
che  Studiengesellschaft  fQr  Kybcrnetik.  Schot- 
tengassc  3,  A-1010  Wien  1,  Austria. 

22-23  April  1976 

Conference  oo  Computer  Law:  The  State  of 
the  Art,  Mark  Hopkins  Hotel.  San  Francisco. 
Calif.  Sponsor:  Computer  Law  Association.  Con¬ 
tact:  CLA,  c/o  E.J.  Grenier  Jr.,  Suite  800,  1666 
K  Street,  Washington,  DC  20006. 

22- 24  April  1976 

■  Annual  ACM  Southeast  Region  Conference, 

University  of  Alabama  in  Birmingham.  Alabama. 
Sponsor:  ACM  Southeast  Region.  Chm:  M.P. 
White.  University  of  Alabama,  Box  88,  University 
Sta.,  Birmingham,  AL  33294. 

23- 24  April  1976 

Symposium  on  Automatic  Computation  and 
Control,  Milwaukee.  Wig.  Sponsors:  IEEE  Mil¬ 
waukee  Section.  IEEE  Systems,  Man  and  Cyber¬ 
netics  Society,  and  University  of  Wisconsin — 
Milwaukee.  Chm:  D.D.  Woelz.  Contact:  J.T. 
Snedekcr.  Engineering  Dept.,  U  W-Extension.  929 
North  Sixth  St..  Milwaukee,  \VI  52303;  414  224- 
4193. 

26-27  April  1976 

Eighth  Annual  Southeastern  Symposium  on 
System  Theory,  The  University  of  Tennessee. 
Knoxville.  Tenn.  Sponsors:  The  University  of 
Tennessee  and  IEEE-CS.  Gen.  chm:  Walter  L. 
Green,  Dep.  of  EE.  The  University  of  Tennessee, 
Knoxville,  TO  37916. 

26-27  April  1976 

■  Symposium  on  Graphic  Languages.  Miami. 
Fla.  Sponsors:  ACM  SIGPLAN  and  ACM  SIG- 
GRAPH  in  coop,  with  Florida  International 
University.  Prog.  Chm:  Tobjf  Berk,  Dep.  of 
Mathematical  Sciences.  Florida  International 
University,  Miami.  FL  33144. 

26-27  April  1976 

Seventh  Annual  Pittsburgh  Modeling  and 
Simulation  Conference,  University  of  Pittsburgh. 
Pittsburgh.  Penn.  Sponsor:  U.  of  Pittsburgh 
School  of  Engineering  in  coop,  with  the  Pitts¬ 
burgh  Sections  of  IEEE  and  ISA.  Co-chm:  Wil¬ 
liam  G.  Vogt  and  Marlin  H.  Mickle,  231  Bene- 
dum  Engineering  Hall.  University  of  Pittsburgh. 
Pittsburgh.  PA  15261. 

3-5  May  1976 

■  Eighth  Annual  ACM  Symposium  on  Theory 
of  Computing,  Hershey.  Penn.  Sponsors:  ACM 
SIGACT  and  Penn  State  University.  Prog,  chm: 
A.K.  Chandra.  T.J.  Watson  Research  Center,  P.O. 
Box  218,  Yorktown  Heights,  NY  10598. 

3-7  May  1976 

14th  Annual  Association  for  Educational 
Data  Systems  National  Convention.  Adams  Hotel. 
Phoenix.  Ari/.  Contact:  Rick  Meyer.  Convention 
Coordinator.  Phoenix  Union  High  School  District. 
2326  W.  Osborn  Road,  Phoenix,  AZ  85017. 

25-28  May  1976  ..... 

■  1976  International  Symposium  on  Multiple* 

Valued  Logic.  Utah  State  University.  Logan.  Utah. 
Co-sponsors:  ACM.  Utah  State  University,  ONR. 
and  IEEE  CS.  Contact:  Stephen  Y.H.  Su.  Dep. 
of  Electrical  Engineering.  Utah  State  U..  Logan. 
UT  84321. 

27  May  1976 

Symposium  on  Trends  and  Applications 
1*76:  MICRO  and  MINI  Systems.  NRS  Gaithers¬ 
burg.  MU.  Sponsors:  IEEE  and  NBS.  Chm:  M.V. 
Zelkowit/.  U.  of  Maryland.  20740;  301  454-4251. 
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PILES  WITH  SEMANTICS 


N.  Minsky 

Rutgers  University 
Hill  Center,  Busch  Campus 
New  Brunswick,  New  Jersey  08903 

•  ^ 

The  conventional  concept  of  file  is  reexamined,  and  found  to  be  unsatisfactory,  both 
as  a  linguistic  concept  in  a  programming  language  and  as  a  tool  foT  data  processing. 

A  new  file  concept  is  proposed  which  unlike  the  conventional  file  attempts  to  simulate 
an  intelligent  archivist  rather  than  a  filing  cabinet. 

INTRODUCTION 

The  concept  of  file  has  an  inportant  role  to  play  in  two  branches  of  computing:  Data  processing  and 
programming  language.  Unfortunately,  both  roles  are  poorly  performed.  The  conventional  file,  as  it  is 
provided  by  most  programming  languages  and  supported  by  most  operating  systems,  is  a  (software)  storage 
device  which  can  be  characterized  by  the  following  two  properties: 

1.  It  handles  an  unbounded  number  of  records  without  any  explicit  relations  between  them  (by  the  term 
"explicit  relation"  we  mean  a  relation  which  is  recognized  and  handled  by  the  (software)  device). 

2.  It  has  no  "semantic  content".  That  is  to  say,  as  far  as  the  conventional  file  is  concerned,  the  data 
Stored  in  it  is  devoid  of  any  meaning;  the  interpretation  of  this  data  is  entirely  up  to  its  users. 

One  can  draw  a  close  analogy  between  such  a  device  and  a  filing-cabinet  (which  is  the  source  of  the  name 
"file").  However  a  filing  cabinet  is  not  what  we  need  in  data  processing.  If  one  has  a  large  amount  of 
Valuable  and  sensitive  information  to  be  shared  by  a  number  of  people,  one  would  rather  have  an  intelligent 
archivist  handle  this  data  than  dump  it  into  a  filing  cabinet.  An  archivist  who  would  have  some  general 
knowledge  3bout  the  records  in  his  custody,  should  be  able  to  validate  the  various  transactions,  thus  pro¬ 
tecting  the  semantic  integrity  and  the  confidentiality  of  the  data;  monitor  the  flow  of  data,  reporting 
various  unusual  events;  etc. 

The  importance  of  such  capabilities  is  widely  recognized,  but  they  are  mostly  considered  ^  in  the  context 
of  database  systems.  However,  since  database  systems  are  designed  to  handle  large  volumes  of  complex  and 
interrelated  data,  they  tend  to  be  very  large  and  expensive.  Therefore,  the  scope  of  application  of  these 
systems  is  somewhat  limited.  We  maintain,  however,  that  one  needs  the  "intelligent  archivist  capabilities" 
for  the  small  business  with  its  mini-computers  and  few  files,  as  well  as  for  the  big  integrated  corporate 
databases.  Moreover,  one  should  be  able  to  get  such  capabilities,  in  this  simple  environment,  without 
paying  the  price  of  a  mammoth  database  system. 

Ona  can,  of  course,  design  a  mini-database  system  which  handles  only  simple  data.  An  example  of  such  a 
system  is  ASAP  [1].  It  is  a  well-designed  system  which  satisfies  many  of  our  requirements.  However,  the 
scope  of  applications  of  ASAP  is  limited  by  the  fact  that  it  is  a  stand-alone  system  to  be  accessed  primar¬ 
ily  by  a  special  purpose  non-procedural  language.  Non-procedural  query  languages  are  very  useful  for  large 
integrated  database  systems,  but  less  so  for  the  more  modest  file  oriented  applications.  The  reason  is 
that  simple  collections  of  data  are  usually  accessed  from  within  a  program  in  the  context  of  some  computa¬ 
tion,  rather  than  in  a  query  type  of  setup.  Therefore,  one  has  to  have  a  convenient  way  for  interaction 
with  such  data  by  means  of  one's  favorite  general  purpose  language. 

This  brings  us  to  the  role  that  the  concept  of  file  plays  in  programming  languages.  Me  will  find,  in 
section  2,  that  the  conventional  file  as  ti  appears  in  most  programming  languages  is  most  unsatisfactory, 
oven  from  the  viewpoint  of  the  host  language  itself. 

The  objective  of  this  paper  is  to  come  up  with  a  new  concept  of  a  file  which  Is  consistent  with  modem 
trends  in  programming  languages  and  which  behaves  more  like  an  archivist  than  like  a  filing  cabinet.  Ex¬ 
amples  are  drawn  from  an  implementation  of  such  a  file  concept  under  the  SI'CILA  language. 


HI  Unfortunately,  due  to  the  complexity  of  database  systems,  many  of  what  we  call  "intelligent  archivist 
capabilities"  are  rarely  implemented,  in  spite  of  the  widespread  recognition  of  their  importance. 

(2)  This  work  was  partially  supported  by  grant  DAHCI5-73-G6  of  the  Advanced  Research  Project  Agency. 


'  LINGUISTIC  VIEW  Or  EILES 


fho  concept  of  file  never  enjoyed  much  popularity  among  programming  language  theorists.  This  was  true  at 
the  very  beginning,  as  the  case  of  ALGOL  [2]  demonstrates,  and  it  is  still  true  today.  Even  the  most 
recent  trends  in  programming  languages  tend  to  leave  the  file  in  essentially  the  same  form  it  had  some  20 
years  ago.  As  a  result  of  this  neglect  most  modem  languages  do  not  answer  satisfactorily  to  the  current 
needs  of  data  processing.  Moreover  as  we  intend  to  show  in  this  section,  the  conventional  file  becomes  a 
liability  to  the  language  itself. 

We  will  restrict  our  discussion  to  one-language  files,  that  is,  to  files  which  are  accessed  only  by  means  of 
programs  written  in  one  given  language.  This  excludes  all  sorts  of  message  transmissions,  such  as  a  file 
which  is  to  be  printed  out.  Also  excluded  arc  files  which  serve  as  communication  media  between  programs 
written  in  different  languages- 

Since  a  file  is  essentially  a  storage  device,  it  is  reasonable  to  expect  it  to  have  a  total  recall  of 
everything  stored  in  it.  This, unfortunately,  is  not  the  case  under  mdst  programming  languages.  A  data 
item  which  is  directly  accessible  to  a  computing  process  usually  carries  two  types  of  information:  The 
value  and  the  semantics  of  the  item.  The  latter  includes  the  tyne  of  the  item  (e.g.,  "integer  array"), 
and  possibly  a  description  of  its  structure  (e.g.,  the  dimensions  of. the  array).  Such  semantic  information 
might  not  be  stored  explicitly  in  the  item;  it  is  nevertheless  known  to  the  language  processor  as  long  as 
tha  item  is  stored  in  the  internal  storage  space  of  the  process.  But  once  an  obicct  is  written  on  a 
file  only  the  value  part  of  the  item  being  output  is  actually  retained.  The  following  quote 
describes  this  phenomenon  in  ALGOL-68  ([3],  page  298),  but  it  could  have  been  written  aoout  FORTRAN, 

COBOL,  PL/ I  and  many  other  languages: 

"In  all  these  [I/O]  procedures,  the  values  are  first  straightened,  and  the  straightened  values  are 
transput.  Thus  all  information  as  to  how  the  original  values  are  divided  into  structures. .. is  lost." 

If  so,  how  are  we  to  reconstruct  the  original  items  when  we  want  to  retrieve  the  information  from  the  file? 
Here  is  what  our  ALGOL-68  source  has  to  say  about  it: 

"If  the  values  output  in  this  way  are  subsequently  read  back  into  a  set  of  structures  identical  to  that 
from  which  they  originally  came,  then  the  new  set  will  be  an  exact  copy  of  the  old." 

Thus,  we  must  know  the  structure  of  the  items  stored  on  a  file  before  reading  them.  This  is.  of  course, 
a  major  inconvenience,  but  it  is  even  worse  than  that.  If  the  content  of  a  file  is  not  read  into  suitable 
structures,  the  result  may  be  a  bunch  of  meaningless  "things",  unrecognizable  by  the  language.  Thus,  the 
file  becomes  a  kind  of  Trojan  Horse  which  can  inject  illegal  values  into  a  process,  violating  the  basic 
rules  of  the  host  language.  For  example,  the  structure  of  many  languages  is  designed  to  guarantee  the 
specified  range  of  variables.  For  instance,  an  integer  number  in  an  ALGOL  program  should  not  find  its  way 
into  a  real  variable.  Nevertheless,  it  can  do  so  by  means  of  a  file:  Just  wTite  the  integer  on  a  file  and 
read  it  back  into  a  real  variable.  Although  this  possibility  is  clearly  contrary  to  the  spirit  of  ALGOL, 
it  say  not  seemto  be  very  damaging.  However,  a  similar  effect,  if  it  happens  go  a  data  structure 
with  a  Ticher  semantic  content,  has  very  serious  consequences,  as  tne  case  of  "protected  objects”  shows. 

A  protected  object  is  a  term  that  we  will  use  for  a  novel  and  important  coqcept  in  programming  languages, 
which  appears,  for  example,  in  some  versions  of  SIMULA  [4]  and  in  CLU  [5]^.  A  protected  object,  or 
Just  "object",  is  an  information  item  which  can  be  manipulated  only  in  a  predefined  way.  Such  an  object 
is  an  instance  of  a  data  type  defined  by  a  module  called  "class"  (because  it  serves  as  a  template  for  a 
Class  of  objects).  The  class  contains  a  description  of  a  structure,  together  with  a  set  of  procedures 
defined  on  such  a  structure.  Some  of  these  procedures  are  labeled  as  the  operators  associated  with  the 
Class,  the  others  are  called  internal  procedures.  The  objects  which  arc  instances  of  a  class  are  protected 
in  the  sense  that  they  can  be  manipulated  only  by  means  of  the  operators  defined  on  them;  the  internal 
Structure  of  an  object,  as  well  as  its  internal  procedures  are  not  visible  from  the  outside.  Consider, 
for  example,  the  following  class  which  defines  stacks: 


2.  will  take  some  liberties  in  describing  this  concept,  borrowing  from  both  SIMULA  and  CLU,  and  using 
our  own  terminology.  The  class  concept  as  described  here,  actually  exists  only  in  the  PDP/10  version 

Of  SIrtJLA. 


CUSS  STACK  (N) ;  INTEGER  N; 

veciN 

STRUCTURE :  INTEGER  ARRAY  A[1:N]; 

INTEGER  TOP; 

OPERATORS : 

PROCEDURE  PUSH  (V);  INTEGER  V; 

IF  TOPcN  THEN  (TOP:=TOP+t  ;A(TOP)  :-Vj; 
INTEGER  PROCEDURE  POP; 

IF  T0P>0  THEN 

lPOP:-A(TOP);  TOP:-TOP-l}; 
INITIALIZATION: 

IF  N-cO  THEN  ERROR; 

T0P;«0 

END; 

An  instance  of  this  class  can  be  generated  by 


S*NEN  STACK  (100). 

Hie  Stack  S  would  consist  of  an  integer  N,  equal  to  100;  an  array  A  of  length  100;  and  an  integer  TOP 
which  is  initialized  to  zero.  These  attributes  of  S  arc  not  visible  from  outside,  as  the  only  way  to 
■anipulatc  S  is  by  means  of  its  operators  PUSH  and  POP.  For  example,  S.PUSH  (7)  pushes  the  number  7  on 
top  of  the  stack,  modifying  the  attribute  TOP  accordingly. 

localise  the  internal  attributes  of  protected  objects  are  inaccessible  from  the  outside,  it  is  possible 
to  design  a  class  of  objects  which  have  some  inherent  properties  that  arc  invariant  to  the  way  a  particular 
object  is  actually  used.  For  example,  the  reader  can  easily  satisfy  himself  that  our  stack  does  "behave' 
like  a  stack".  It  is  clear  that  the  ability  to  generate  information  objects  which  have  a  well  defined 
Structure  and  behavior  can  contribute  immensely  to  the  reliability  of  programming,  to  our  ability  to  prove 
correctness  of  programs,  and  to  well  structured  programming  in  general.  The  reader  is  referred  to  [S]  for 
further  discussion  of  this  important  concept.  Here,  we  will  use  the  concept  of  protected  objects  in  two 
ways:  First,  we  will  show  that  it  is  not  compatible  with  conventional  files.  Later  on  we  will  suggest,  as 
•  solution  to  this  problem,  that  the  file  itself  can  be  viewed  as  a  kind  of  protected  object. 

T^ero  are  essentially  two  ways  to  store  and  retrieve  a  composite  structure  on  a  file: 

TT  can  take  the  structure  apart,  storing  (retrieving)  each  of  its  components  separately. 

2)  He  can  treat  the  structure  as  an  indivisible  entity,  expecting  the  language  processor  to  do  the  actual 
work  for  us. 

loth  these  methods  are  not  suitable  for  protected  objects.  The  first  method  is  not  available  because  the 
attributes  of  the  object  are  not  accessible  from  the  outside,  and  therefore  cannot  be  output  one  by  one. 

As  to  the  second  method,  suppose  that  there  is  a  stack  of  size  N’stored  in  the  "current"  position  of  a 
file  F.  Following  the  standard  procedure  (of,  say,  ALGOL-68),  and  supposing  that  N  is  known,  we  can 
retrieve  the  stack  as  follows:  First,  we  generate  a  suitable  empty  structure  by  writing 

S*NEW  STACK (N). 


Host,  we  can  write  something  like 


READ  FROM  F  INTO  S, 

expecting  S  to  be  filled  with  information  from  the  file.  The  problem  here  is:  Khat  if  in  fact  the  content 
of  the  file  is  not  a  stack  of  size  N,  or  not  a  stack  at  all?  S  would  then  he* filled  with  arbitrary  infor¬ 
mation,  which  may  not  satisfy  the  "inherent  properties"  of  a  stack.  For  example,  the  attribute  TOP  of  S 
■ay  well  be  negative,  or  greater  than  N.  Obviously,  our  expectations  as  to  the  behavior  of  S  would  not  be 
satisfied. 

Thus,  the  only  available  method  to  store  and  retrieve  protected  objects  from  a  conventional  file  destroys 
Che  vary  essence  of  the  concept  of  protected  objects. 

One  can,  of  course,  legislate  tha-.  protected  objects  should  not  be  stored  on  a  file  at  all,  but  this 
would  be  a  most  unreasonable  restriction.  For  example,  such  a  restriction  introduces  an  unjustified 
aoaantic  distinction  between  an  internal  1 incar-1 inkcd-list  of  objects,  and  a  sequential  "intraprocess 
file”.  Such  a  file  behaves  essentially  as  a  list.  The  only  real  difference  between  these  two  structures 
is  one  of  speed,  similar  to  the  difference  between  a  page  on  a  disk  and  one  in  core  memory,  under  a  vir¬ 
tual  memory  system. 

•she  Inevitable  conclusion  from  all  this  is  that  the  conventional  semantic-less  file  is  inconsistent  with 
the  underlining  philosophy  of  many  programming  languages. 


•-  step  towards  a  linguistically  consistent  concept  of  file  has  been  taken  in  the  language  PASCAL  (6):  If  RT 
.  mm  PASCAL  type,  then  the  declaration 

TYPE  FT  -  FILE  OF  RT 

defines  FT  to  be  a  file-type.  An  instance  of  FT  can  be  generated  by 

VAR  F :FT. 

P  is  a  file  in  which  only  records  of  type  RT  can  be  stored.  Thus,  the  domain  of  a  PASCAL  file  is  restrict¬ 
ed,  just  as  the  domain  of  internal  variables,  by  type  specification. 

The  PASCAL  file  concept,  just  described,  leaves  a  serious  'problem  unsolved:  Suppose  that  a  file  F  of  type 
FT  was  generated  by  a  process  P  and  is  to  be  read  by  another  process  P1.  How  can  P*  handle  the  records 
of  type  RT,  retrieved  from  F,  if  the  type  RT  is  defined  in  P?  The  structure  of  these  records  would  be 
illegal,  indeed  meaningless  in  P’  because  the  definition  of  their  type  is  not  available  to  it. 

This  problem,  and  its  solution,  are  best  viewed  in  the  context  of  block  structured  languages.  It  is  a 
basic  principle  of  such  languages  that  if  an  object  q  is  an  instance  of  type  T,  the  "life  time"  of  q 
cannot  exceed  that  of  the  type  T  itself.  The  life  time  of  a  type,  in  turn,  is  identical  to  that  of  the 
block  in  which  it  is  defined.  Our  problem,  now,  is  the  following:  The  file  F  which  is  to  be  used  by  two 
processes  may  outlive  both  of  them.  Therefore,  the  file-type  FT,  as  well  as  the  record  type  RT,  must  be 
defined  in  a  block  which  is  outer  to  both  processes.  The  problem  is  that  under  most  languages  such  a 
block  does  not  exist,  because  a  program,  and  any  process  induced  by  it,  is  commonly  considered  to  he 
linguistically  autonomous.  This  problem  can  be  rectified  by  the  following  natural  extension  of  the  block 
structure  concept: 

Every  program  (in  a  given  language)  is  to  be  viewed  as  if  it  operates  within  a  unique  outer  block,  of 
indefinite  life  time,  to  be  called  "the  external  environment",  or  E.  E  would  contain,  among  other  things 
the  definition  of  various  types  of  records,  such  as  RT  above,  and  of  various  file-types,  such  as  FT. 
Obviously,  there  should  be  a  way  to  introduce  such  definitions  into  E.  It  is  also  necessary  to  establish 
some  protocal  by  which  a  program  gains  access  to  desired  parts  of  E.  (The  ALGOL-like  scope  rules  under 
which  the  entire  block  is  visible  from  all  its  inner  blocks  is  clearly  unsuitable  here).  Such  protocal, 
sod  the  techniques  which  might  be  used  for  the  maintainance  of  E,  are  beyond  the  scope  of  this  paper,  but 
an  example  will  bo  given  later. 

Thus,  for  a  file  to  outlive  the  process  which  generates  it,  it  is  necessary  that  the  type  definition  of 
this  file  resides  in  the  external  environment  E.  Some  standard  file-types  should  reside  in  E  permanently, 
such  as  a  file  whose  records  are  character  strings.  But  if  one  wants  his  file  to  contain  records  of  a  user 
defined  type,  and  if  this  file  is  to  outlive  the  process  which  generates  it;  then  the  record-type,  along 
with  an  appropriate  file-type, should  be  first  defined  into  E. 
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A  DATA  PROCESSING  VIEW  OF  FILES 


The  PASCAL- like  file-type,  with  the  elaboration  discussed  above,  is  quite  satisfactory  from  the  viewpoint  of 
programming  languages,  but  it  does  not  answer  the  needs  of  data  processing.  When  designing  a  file  which  is 
to  carry  valuable  and  sensitive  information,  it  is  not  enough  to  specify  the  sturcture  of  the  records  to  be 
Stored  in  it.  One  would  like  to  determine  some  ground  rules  under  which  it  is  to  operate.  A  linguistic 
tool  which  is  suitable  for  this  purpose  is,  again,  the  SIMULA  "class",  (or  rather,  the  protectable  class  as 
in  the  PDP/10  version  of  SIMULA) .  In  the  following  section  we  will  describe  the  main  features  of  an  imple- 
aentation  of  our  file  concept,  where  a  file-type,  or  rather,  a  file-class  is  defined  by  means  of  a  SIMULA 
class.  The  file  itself  would  be  a  protected  object  which  is  an  instance  of  such  a  class. 

The  Content  of  a  File 


As  was  pointed  out  in  the  introduction,  one  of  the  main  features  of  a  file,  which  distinguishes  it  from  a 
database,  is  the  simplicity  of  the  data  stored  in  it.  It  should  be  simple  enough  not  to  require  a  complex 
system  to  handle  it.  To  see  what  this  means,  observe  that  the  complexity  of  databases  is  due  primarily 
to  the  fact  that  they  have  to  handle  data  which  is  both  large  and  structurally  complex.  There  is  no  great 
difficulty  in  dealing  with  large  numbers  of  non-related  records:  the  conventional  file  does  that.  Nor  is 
•  there  any  real  difficulty  in  dealing  with  structurally  complex  data,  if  it  can  be  kept  in  main  memory.  It 
setwis  the  combination  of  these  two  properties  that  is  difficult  to  handle,  and  which  we  must  avoid  when  dealing 

M  files-  would 


Ve  propose,  acccvdingly,  that  the  content  of  a  file*consist  of  two  parts,  to  be  called  the  "record  space" 
(R) ,  and  the  "global  space"  (G) ,  defined  as  follows: 


(1)  The  Record  Space  (R)  is  an  unbounded  (usually  large)  number  of  records  without  any  interrecord 
relations.  As  in  the  case  of  conventional  files,  only  one  record  of  P  will  be  handles  by  the  file 
at  any  moment  in  time;  it  will  be  called  the  "current  record"  of  the  file,  to  be  denoted  by  C. 

(2)  The  Global  Space  (G)  is  a  relatively  small  data  structure,  of  an  arbitrary  structural  complexity. 
It  should  be  small  enough  to  be  wholly  contained  in  the  main  memory,  if  necessary. 


The  record  space  is  of  course  the  counterpart  of  the  entire  content  of  the  conventional  file.  The  new  ele- 
aant  hero  is  the  global  space.  As  we  will  see  later,  all  of  G  is  to  be  accessible  during  any  interaction 
with  the  file.  This  should  not  contribute  significantly  to  the  complexity  of  the  file  system,  due  to  the 
assumed  small  size  of  G.  The  global  space  contains- information  which  pertains  to  the  f! le  as  a  whole,  as 
well  as  information  which  is  common  to  all  records  in  R.  As  we  will  see  later,  G  can  be  viewed  as  a  kind 
of  environment  in  which  all  the  records  in  0  arc  defined.  The  role  of  G  in  our  model  is  best  explained  in 
the  context  of  the  dynamic  behavior  of  a  file,  which  is  discussed  next. 


The  Dynamic  Behavior  of  Files 

Die  dynamic  behavior  of  a  file  is  determined  by  the  procedures  built  into  the  file-class  of  which  it  is  an 
instance.  During  interaction  with  a  file,  these  procedures  have  access  to  the  entire  global  space  (G)  and 
to  just  one  record  of  R.  This  is  the  "current  record",  C,  which  serves  as  a  window  that  moves  across  R. 
Since  G  is  constantly  available,  it  can  be  examined  and  updated  both  by  er.ilzcit  user's  instructions,  and, 
behind  the  scenes,  by  various  file  procedures,  (see  figure  1). 


The  file  procedures  can  be  classified  into  the  following  categories: 

1.  The  Operators  of  the  file.  This  category  includes  the  conventional  file  operators  such  as  OPEN,  FIND, 
STORE,  DELETE,  etc.,  as  well  as  less  familiar  ones  to  be  mentioned  later. 

2.  The  Internal  Procedures  which  are  not  visible  from  the  outside  and  which  perform  various  activities 


*■  Mnd  the  scenes ,  as  described  below. 

The  tele  of  the  internal  procedures  of  a  file  and  of  its  global  space  can  be  illustrated  by  the  following 
classification  of  the  activities  which  night  be  performed  by  the  file  without  the  explicit  knowledge  of  its 
users. 

a)  Protection  of  the  Integrity  of  a  File:  Various  validity  checking  routines  can  be  coded  as  internal  pro¬ 
cedures  of  the  file-class,  and  invoked  by  the  operators  whenever  appropriate.  These  procedures  would  usu¬ 
ally  depend  on  parameters .such  as  the  permissible  bounds  of  various  components  of  a  record.  Since  such 
parameters  arc  relevant  to  all  the  records  in  the  file  they  should  be  stored  in  C.  The  role  of  G  here  is 
crucial.  In  a  system  like  ASAP  [I],  for  example,  which  does  not  have  any  global  space,  the  information 
which  Is  necessary  for  validity  checking  is  stored  in  the  local  space  of  the  validity-checking-routincs. 

This  is  unsatisfactory  on  two  accounts.  First,  the  same  information  item  might  have  to  be  repeated  in 
aaveral  routines.  The  second,  more  serious,  problem  is  that  such  information  is  not  subject  to  convenient 
tpdate/retrieval  procedures.  In  our  case,  on  the  other  hand,  the  information  in  G  can  be  manipulated  by 
qualified  users  just  like  the  rest  of  the  file. 

b)  Monitoring:  The  importance  of  monitoring  the  activity  of  a  file  is  aptly  explained  by  Conway,  Maxwell, 
and  “organ  in  (7) .  Here  are  two  examples  borrowed  from  that  paper: 

(1)  In  an  accounts  receivable  system  someone  could  be  responsible  for  monitoring  the  activity  of  a 
certain  subset  of  accounts  (perhaps  because  they  are  especially  good  customers,  or  because  they 
ax*  especially  bad  credit  risks)  and  want  to  be  informed  of  any  transaction  that  affects  the 
balance  of  any  of  these  accounts. 

(2)  In  an  inventory  system  a  particular  item  might  be  depleted  and  back-ordered  and  a  user  might  wish 
to  be  notified  as  soon  as  replenishment  takes  place. 

Of  course,  such  monitoring  must  be  done  without  the  explicit  knowledge  of  the  users  who  interact  with  the 
file.  In  our  system,  the  monitoring  will  be  perfomred  by  special  objects  called  demons  which  are  activated 
by  the  file  system  under  a  specified  set  of  circumstances.  The  procedural  part  of  these  demons  must  be  pre¬ 
defined  (as  part  of  the  definition  of  the  file),  but  demons  can  be  activated  and  deactivated  by  qualified 
users  during  the  lifetime  of  the  file. 

-C)  Maintenance  of  the  File  Status  and  History:  The  global  space  can  be  used  to  carry  information  about 
the  current  status  of  a  file  and  about  its  history.  Such  information  can  be  computed  routinely  by  the 
various  operators  and  by  some  of  the  demons  mentioned  above.  Examples  of  information  that  one  may  want  to 
aalntain  in  G  are:  the  total  number  of  records  in  the  file;  various  aggregates  such  as  the  current  bal¬ 
ance  in  an  accounting  file;  some  statistics  about  the  past  activities  of  the  file,  etc.  The  only  limit 
here  is  the  size  of  G  which  must  stay  fairly  small. 

4)  Access  Control:  G  can  be  used  to  store  information  about  the  access  rights  of  various  classes  of  users, 
(rouped  into  structures  called  "user  profiles'.'.  Mien  a  file  is  opened,  an  appropriate  user  profile  is 
selected  to  be  later  consulted  by  the  various  operators.  In  our  current  design  there  is  a  standard  access 
control  mechanism  based  on  security  levels  and  compartments  (as  in  ADAPT-SO  [8]).  In  addition,  there  are 
built-in  hooks  on  which  one  can  hang  procedural  access  control  of  arbitrary  generality,  as  in  [9],  Note 
that  the  manipulation  of  G  as  well  as  that  of  R  should  and  can  be  under  access  control,  this  is  true,  in 
particular,  for  the  manipulation  of  the  user-profiles  themselves. 

•)  Transformation  of  Data:  Several  types  of  data  transformation  may  be  necessary.  Here  are  the  most  im- 
portant  of  them: 

1.  Enciphering  and  deciphering  of  stored  data  for  security  purposes.  The  keys  which  are  necessary  for 
this  transformation  can  be  stored  in  G  and  would  be  subject  to  user  interaction  under  the  restriction  of 
the  access  control  mechanism. 

2.  A  transformation  between  the  logical  and  physical  representations  of  the  records  in  R.  Such  a  trans¬ 
formation  may,  in  particular,  save  space  by  performing  data  compaction  and  by  eliminating  redundancy. 

3.  Transformations  between  an  actual  record  in  the  file  and  users'  views  of  it  (these  are  the  schema- 
tubschema  transformations,  as  in  the  DBTG  proposal). 

To  Illustrate  the  use  of  our  files,  suppose  that  there  is  a  file  class  PAYROLL  In  the  environment  E.  Also 
in  E,  there  is  a  class  EMPLOYEE,  which  defines  the  structure  of  the  records  in  payroll-classes;  and  the 
class  SUMMARY  which  defines  one  of  the  structures  in  the  global  space  G  of  payroll-files.  (G  may  have 
etner  parts  which  will  not  concern  us  hoTe.)  Suppose  also  that  there  are  in  the  system  two  "payroll  files" 
Called  "paTt-time"  and  "full-time".  (The  ter*  "payroll  files"  means  that  these  files  are  instances  of  the 
Class  PAYROLL). 

Non,  a  user  who  wishes  to  Interact  with  any  payroll  file  exist  have  in  his  program  the  declaration 
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EXTERNAL  PAYROLL.  EMPLOYEE,  SU*f1ARY. . . 
which  incorporates  these  classes  into  the  user's  program. 

An  internal  data  structure  which  can  be  used  for  the  interaction  with  a  payroll  file  can  now  be  generated 
by 

F  *  NEW  PAYROLL 

P  will  be  called  a  "file  anchor".  To  associate  F  with  a  specific  payroll  file,  the  file  "full-tine"  say, 
on*  writes: 

P, OPEN ("FULL-TIME", USER-PROFILE, PASSWORD) . 

This  operation  opens  the  naaed  file,  if  an  appropriate  password  is  provided  for  the  requested  user- 
profile. 

The  file  "full-time"  can  now  be  manipulated  and  interrogated  by  applying  various  file  operators  to  the 
anchor  F.  For  example,  assuming  that  F  is  an  indexed  file,  and  that  the  index  is  the  name  of  an  employee, 
one  can  retrieve  a  specific  employee  record  by 

e  ♦  F. FIND ("name") 

The  record  e  would  be  an  instance  of  class  E"PLPYEE  and  can  be  used  as  such.  (Recall  that  the  definition 
of  class  EMPLOYEE  is  included  in  the  user's  program). 

An  employee  record  e  which  is  generated  by  the  user  can  be  stored  in  the  file  by 

P.STOPE(e). 

Let  us  use  the  STORE  operation  to  illustrate  the  behind-the-scenes  activity  of  the  file.  The  following 
STS  the  actions  which  might  be  invoked  by  the  STORE  operator: 

(a)  The  validity  of  e  is  checked,  as  well  as  the  right  that  the  current  user  has  to  store  such  a 
record. 

(b)  The  various  "demons"  which  are  supposed  to  monitor  the  store  operation  are  invoked. 

(c)  The  record  e  may  be  transformed  into  an  internal  representation,  which  is.  presumable,  more 

economical. 

(d)  The  Tecord  is  enciphered. 

(e)  Finally,  the  transformed  and  enciphered  record  is  stored,  using  the  key  defined  in  it,  if  any. 

Of  course,  the  nature  of  these  activities,  and  whether  they  exist  for  this  particular  file,  depends  on 
the  class  PAYROLL,  (see  also  next  section) . 

The  global  part  of  the  file  can  also  be  retrieved  and  updated.  Here  is  an  example.  We  already  assumed 
that  our  G  includes  a  record  which  is  an  instance  of  class  SUMMARY.  This  record  may  have  an  attribute 

such  as  (employees,  which  is  to  be  maintained  by  the  various  "demons"  of  the  file.  The  summary  record 

can  be  retrieved  by 

S  ♦  P.6ET-GL0BAL("summary") , 

where  the  returned  object  's'  is  a  summary  record.  The  number  of  employees  in  the  file  are  now  accessible 
by  s. (employees. 

Uhtil  now  we  discussed  only  the  standard  file  operators,  which  exist  for  any  file.  One  can  also  define 
operators  which  are  specific  to  a  certain  file-class.  For  example,  it  may  be  very  convenient  to  define 
into  our  employee  file  an  operator  RF.POPT  which  prints  a  report  about  an  employee,  or  an  operator  I’RINT- 
CHECK(k)  which  prints  a  paycheck  for  Jk ,  for  the  current  employee.  The  incorporation  of  such  data  depen¬ 
dent  operators  into  the  file  itself  may  save  a  lot  of  coordination  efforts  between  programmers  and  pro¬ 
gram.  It  is  a  key  to  "data  independent"  file  processing. 

As  a  final  example  let  us  show  how  a  new  payroll  file  can  be  generated.  The  first  step  is,  again,  a 
generation  of  an  anchor 

P  A-  NEW  PAYROLL 

Now  we  have  to.  load  F  with  the  desired  initial*  G,  a  step  which  will  not  be  described  here  due  to  lack  of 
space.  Next  we  write 

P.GENFIL£(filcname,  access-node,...). 


T*>»*  operator  generate,*  a  new  payroll  file  whose  name  Is  the  first  parameter  anJ  whose  ncccss-moUc  is 
.  tlficd  by  the  second  parameter.  It  is  assumed  here  that  we  have  a  repertoi re  of  access  modes  available 
to  us,  such  as  "sequential",  "ISAM",  etc.  The  specific  access  mode  of  a  file  must  be  determined  when  the 
file  is  generated.  Note,  however,  that  to  a  large  extent,  the  interaction  with  an  existing  file  may, and 
should,  be  independent  of  its  access  mode. 

On  the  Definition  of  a  File-Class  1 

As  was  already  pointed  out,  a  file  class  is  defined  by  means  of  a  module  which  determines  both  the  struc¬ 
ture  of  the  file's  content  and  its  behavior.  The  problem  here  is  that  some  of  these  characteristics  are 
peculiar  to  a  given  file,  while  others  are  common  to  all  files  and  should  be  defined  once  and  for  all,  for 
a  given  language.  Thus,  a  file-class  should  be  defined  jointly  by  the  language  and  by  an  individual  user. 
Fortunately,  there  is  in  SIMULA  a  ready  made  tool  for  such  joint  definitions,  it  is  the  ability  to  extend 
s  Class  as  follows:  A  given  class  Cl  can  be  extended  by  the  module 

Cl  CLASS  C2  BEGIN... F.NP 

The  resulting  class,  C2,  consists  of  all  the  attributes  of  Cl  together  with  all  those  defined  inside  the 
BEGIN. ..END  bracket.  C2  is  thus  an  "extension''^)  of  Cl,  while  Cl  is  called  the  "prefix”  of  C2.  We  will 
also  refer  to  C2  as  a  "Cl-class". 

Two  properties  of  this  linguistic  device  of  SIMULA  are  important  for  us  here.  First,  a  class  can  have  any 
ausber  of  different  extensions.  Secondly,  certain  parts  of  a  prefix  can  be  redefined  in  its  extensions. 

The  class-extension  capability  of  SIMULA  suggests  the  following  approch  to  the  definition  of  files: 

First,  there  should  be,  in  the  environment,  a  standard  class  called  FILE  which  contains  all  the  structures 
and  procedures  that  are  common  to  all  files.  For  example,  operators  like  FIND,  STORE,  OPEN... would  be 
defined  in  FILE.  Also  in  FILE,  there  would  be  various  default  procedures  which  could  be  redefined  later. 

A  specific  file-class  would  be  defined  as  an  extension  of  the  class  FILE,  to  be  called  a  "semantic  exten¬ 
sion"  of  FILE.  This  extension  would  contain  everything  which  depends  on  the  identity  of  a  specific  class 
of  files.  The  only  mandatory  part  in  the  semantic  extension  is  the  specification  of  the  type  (class)  of 
tho  records  in  R.  Indeed,  a  conventional  type  of  text-file  can  be  defined  simply  by  the  following  module: 

FILE  CLASS  TEXTFILE; 

w* 

BEGIN  TEXT  RECORD  END; 

Note  that  the  G  part  of  this  file  is  empty.  Optionally,  however,  one  can  put  many  more  details  into  the 
semantic  extension  of  FILE.  For  example,  the  specification  of  C,  various  validation  routines,  access  con¬ 
trol  procedures,  enciphering  procedures,  etc.  All  that  can  be  done  in  a  very  modular  way  since  the  general 
framework  and  the  control  structure  are  already  defined  in  FILE.  Unfortunately,  space  limitations 

do  not  allow  us  to  present  a  complete  example  of  a  definition  and  use  of  a  file. 

CONCLUSION 

The  current  state  of  the  art  of  information  processing  tends  to  link  capabilities  such  as  protection  of 
data  integrity  and  its  confidentiality,  monitoring  the  interactions  of  users  with  the  data,  etc.,  with 
large  database  systems.  This  is  most  unfortunate  since  such  capabilities  arc  frequently  vital  for  modest 
applications  which  do  not  have  the  degree  of  data  complexity  to  justify  the  use  of  large  database  systems, 
and  which  may  not  be  able  to  afford  them.  In  this  paper  we  tried  to  demonstrate  that  what  we  called 
"intelligent  archivist's  capability”  can  be  implemented  as  a  standard  feature  of  a  programming  language, 
without  the  large  overhead  associated  with  database  systems. 

The  paper  is  based  on  an  actual  implementation  under  the  SIMULA  language.  It  is  still  an  open  question, 
however,  as  to  how  to  implement  an  equivalent  file  system  into  a  more  common  language,  like  COBOL. 
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(1)  We  ere  taking  some  liberties  with  the  SIMULA  concepts  and  tenainology.  For  example,  in  SIMULA,  C2  is 
called  a  subclass  of  Cl. 
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•figure  1;  An  Illustration  of  the  file  structure  • 

A  user  communicates  with  a  file  by  means  of  its  operators.  These,  and  the  other 
ffcle  procedures  have  an  access  to  the  "current  record",  which  moves  across  R  like 
a  window,  as  well  as  to  the  entire  "global  space"  of  the  file. 
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Abstract 


The  Lattice  model  for  secure  information  flow  proposed  by 
Dorothy  Denning  is  found  to  be  unjustified  in  a  number  of  cases. 
A  modification  to  this  model  is  proposed,  which  allows  for 
controlled  violations  of  the  lattice  discipline. 
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In  a  recent  paper,  [1]  Dorothy  Denning  proposed  a  very  attractive 


lattice  model  for  "secure  information"  flow.  Although  this  model 
successfully  handles  many  aspects  of  the  problem  at  hand,  it  fails  to 
represent  certain  important  flow  patterns  of  information,  which  do  not 
behave  like  a  lattice.  These  non-lattice  properties  will  be  identified, 
and  a  way  to  modify  the  original  lattice  model  to  cover  them  will  be 
proposed.  We  start  with  a  brief  summary  of  the  lattice  model,  assuming 
that  the  reader  is  familiar  with  Denning's  paper. 

The  information  flow  model,  FM,  is  defined  by 
FM  =  <N,P,SC,  ,  Qj  >  ,  where: 

P  is  a  set  of  processes  (which  will  not  concern  us  directly  here), 

N  =  {a,b,,..}  is  a  set  of  objects,  and  SC  a  set  of  security  classes. 

Every  object  aeN  is  bound  to  a  security  class  aeSC,  although  the  binding 
is  not  necessarily  permanent. 

is  a  relation  defined  on  SC,  called  the  flow  relation.  It  has 
the  following  meaning:  For  A,BeSC,  the  relationship  A-+B  means  that 
information  in  class  A  is  allowed  to  flow  into  class  B.  The  algebraic 
structure  <SC,  -+•  >  is  assumed  to  be  a  partially  ordered  set. 

is  a  binary  operator  defined  on  SC.  The  following  is  assumed 
about  it:  Let  a,b  be  objects  in  N,  and  let  a_,  b  be  the  security  classes 
associated  with  them.  It  is  assumed  that  the  security  class  associated 
with  f  (a,b) ,  for  any  function  f,  is  ag)  b.  (We  will  find  below  that  this 
assumption  is  not  always  justified). 
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Now,  it  is  claimed  in  [1]  that  under  a  set  of  assumptions  which 
follow  from  the  semantics  of  secure  information  flow,  the  algebraic 
structure  <SC,  -»•,©>  forms  a  lattice  in  which  "  (±>  "  is  the  "least- 
upper-bound"  operator.  One  of  the  assumptions  which  supports  this  claim 
is  the  following: 

For  any  A,BeSC  the  following  relations  are  satisfied  (in  the  "real 
world"  of  secure-information-flow,  that  is). 

A  -*■  A  ®  B  and  B  -+  A  (+>  B 

"Without  this  property",  it  is  said,  "we  would  have  the  semantic  absurdity 
that  operands  could  not  flow  into  the  class  of  the  result  generated  from 
them".  This,  however,  is  not  absurd  at  all,  as  the  following  example 
illustrates. 

Consider  the  function  encipher  (plaintext,  code) .  The  two  para¬ 
meters  of  such  a  function  would  usually  have  high  security  classification 
while  the  security  level  of  the  outcome  of  the  encipher  function  is 
relatively  low.  Indeed  the  whole  purpose  of  enciphering  is  to  generate 
an  image  of  a  confidential  plaintext  which  can  be  sent  via  public  channels, 
or  be  stored  on  loosely  protected  files.  The  outcome  of  encipher  must 
therefore  have  a  lower  security  classification  than  its  arguments.  Thus, 
we  do  not  have  in  this  case  the  relation 

plaintext  -*■  plaintext  ©  code 

Moreover,  this  example  shows  that  one  cannot  expect  the  security  level 
of  f(a,b)  to  be  the  same  for  all  functions  of  f. 


The  crux  of  the  matter  is  that  the  lattice  discipline  does 
not  allow  any  reduction  of  the  security  classification,  where  such  a 
reduction  is  frequently  vital  and  justified.  for  instance,  our  enciphering 
example  is  based  on  the  beliefs  that  it  is  impossible,  or  very  difficult,  to 
figure  out  the  plaintext  from  its  coded  version,  there  is  thus  no 
reason  for  the  latter  not  to  have  a  lower  security  class  then  the 
former.  As  another  example  of  reduction,  consider  a  function  summari  ze  (f) 
which  produces  a  summary  of  the  content  of  a  file  f.  Even  if  every 
record  of  f  may  be  of  high  secur:ty  classification,  the  function 
summarize  may  be  carefully  programmed  to  produce  only  an  insensitive 
summary  of  it.  There  is  no  reason  not  to  give  this  summary  a  low 
classification.  As  a  final  example,  there  should  be  somebody  in 
any  organization  who  has  the  power  to  declassify  items  of  information. 

Such  power  must  be  reflected  in  the  computerized  information  system, 
but  it  is  not  compatible  with  the  lattice  discipline. 

In  spite  of  all  this,  the  lattice  remains  an  eminently  suitable 
model  in  many  ways,  and  should  be  retained  whenever  possible.  I  am 
proposing,  therefore,  a  "semi- lattice"  model  for  secure  information 
flow,  which  is  based  on  Denning's  lattice,  but  accommodates  some  controlled 
violations  of  it.  The  permitted  lattice  violations  are  defined  by 
rules  of  the  form 

Cq  <f,c1,...,cm>, 

where  f  is  an  identifier  of  a  given  n-ary  function,  such  as  our  encipher 
function  above,  c^,  for  i=l,...,n  arc  the  security  classes  of  the 


parameters  of  f,  and  is  the  security  class  of  the  outcome  of  f.  There 
is  no  arrrj ori  relation  between  c^  and  Cj,...,cm.  Cq  is  determined  arbi¬ 
trarily  by  the  rule  above.  Consider,  for  example,  the  case  illustrated 
in  Figure  1.  Suppose  that  is  the  class  associated  with  the  enciphering 
code  and  is  associated  with  the  plaintext  to  be  enciphered.  In 
addition  to  the  flow  permitted  by  the  lattice,  represented  by  solid  lines 
in  Figure  1,  suppose  that  there  is  the  rule: 

Aq  <encipher, 

This  rule  means  that  the  outcome  of  encipher,  when  applied  to  parameters 
of  classes  A^  and  A^,  should  be  associated  with  the  lowest  class,  A^. 

(In  Figure  1  such  rules  are  represented  by  diamond  shaped  figures,  and 
the  corresponding  lattice-violating  flows  by  dashed  links) .  Another 
violation,  in  this  example,  is  permitted  by  the  rule 

A  declassify,  A3>. 

Clearly,  the  use  of  some  of  these  lattice-violating  functions,  such  as 
declassify,  must  itself  be  restricted,  lest  it  be  abused.  Therefore, 
a  model  such  as  this  must  reside  in  a  tightly  controlled  computing  envir¬ 
onment.  For  example,  the  formalism  proposed  in  [2]  is  based  on  rules  which 
are  very  similar  to  the  ones  used  here  and  might  provide  a  suitable 
environment  for  the  semi- lattice  model. 

Finally,  it  should  be  pointed  out  that  the  various  enforcement, 
techniques  proposed  in  [1]  are  still  valid  for  the  semi-lattice  model 


described  here. 


£  code 


The  solid  links  between  the  security  classes  A^,...,A^  form 
a  lattice.  The  diamond  shaped  boxes  represent  lattice-violating 
functions,  and  the  dashed  links  represent  lattice-violating  flow 


of  information. 
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PROTECTION  IN  PROGRAMMING  LANGUAGES  BY 


__  OPERATION-CONTROL 


Abstract 


Protection  in  programming  languages  has  to  do  with  dispersion  of 

Srivileges  among  the  various  modules  of  the  program.  This  is  being 
one  in  most  languages  by  means  of  scope  rules.  Recently  it  has  been 
proposed  to  incorporate  into  languages,  an  access-control  facility 
which  is  modeled  after  the  capability-based-protection  mechanism 
provided  by  some  operating  systems.  This  paper  proposes  a  further 
enhancement  of  our  ability  to  disperse  privileges,  by  the  introduction 
of*  a  new  control-object  called  activator,  which  represents  privileges 
with  respect  to  an  operator .  The  resulting  protection  scheme^  to  be 
called  operation-control,  is  based  on  the  access-control  facility,  but 
it  is  more  general  and  often  more  efficient  than  the  latter. 
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ii  INTRODUCTION 

By  the  term  "protection"  we  mean,  the  ability  to  impose 
restrictions  on  a  program,  restrictions  which  cannot  be  violated  by  the 
program  itself  regardless  of  the  actual  code  in  it.  These  restrictions 
may  be  imposed  on  a- program-module  from  the  outside;  or,  they  may  be 
voluntary  restrictions  introduced  by  declarations,  say.  Such 
restrictions  are  the  basis  for  effective  modularization,  and  they 
facilitate  program-verification,  either  manual  or  automatic. 
Protection  is  therefore  essential  for  the  production  of  reliable 
software.  It  is  particularly  crucial  for  the  design  of  large  systems 
with  many  modules,  where  the  controlled  sharing  of  information  is 
imperative. 

One  may  distingwish  between  two  types  of  restrictions,  to  be 
called  "semantics-based-restrictions"  and 
•privilege-based-restrictions".  The  objectives  of  the  former  type  of 
restrictions  is  to  guarantee  the  semantic  integrity  of  the  various 
data-structures  manipulated  by  a  program,  and  to  prevent  meaningless 
operations  from  being  carried  out.  The  privilege-based-restrictions, 
on  the  other  hand,  have  to  do  with  a  dispersion  of  privileges  among  the 
various  modules  of  a  program,  in  order  to  limit  the  set  of  legal 
operations  which  can  be  carried  out  by  any  given  module.  Although  the 
boundery  between  these  two  types  of  restrictions  is  not  sharply 
defined,  the  distinction  between  them  would  give  us  a  convenient  frame 
of  reference.  This  paper,  in  particular,  is  concerned  primarily  with 
the  second  type  of  restrictions.  But  before  we  get  to  that,  a  brief 
review  of  the  current  state  of  the  art  of  protection  in  languages  is  in 
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Most  of  the  semantics-based-restrictions  facilitated  by 
programming  languages  are  associated  with  the  concept  of  type.  A 
notable  example  is  provided  by  languages  like  CLU  [Lis74]  ,  ALPHARD 
lWul75]  and  some  versions  of  SIMULA  [Dah72 ,Pal73J .  In  these,  and  other 
languages,  the  type  definition,  of  a  given  type  t,  in  addition  of  being 
a  template  for  all  instances  of  t,(  which  we  will  call  t-objects) ,  also 
contains  a  set  of  procedures  to  be  called  t-operators  (*) .  These 
operators  have  the  exclusive  direct  access  to  t-objects.  That  is  to 
say,  the  only  way  to  observe  or  update  a  t-object,  from  any  place  in  a 
program  outside  of  the  module  which  defines  t,  is  indirectly,  by  means 
of  the  t-operators.  The  great  usefulness  of  this  concept  for 
reliability  of  programming  was  aptly  described  by  Liskov  and  Zilles 
[Lis74] . 

Turning  now  to  the  privilege-based-restrictions,  the  best  known 
examples  of  these,  are  the  "scope-rules"  which  form  the  block-structure 
in  many  languages.  The  effect  of  these,  and  other  more  general 
scope-rules  [Wul74,  Dij76J ,  is  to  restrict  the  set  of  objects  which  are 
accessible  to  a  given  module.  Note,  however,  that  the  accessibility  of 
an  object,  as  determined  by  the  scope  rules,  is  usually  an 
all-or-nothing  matter.  Namely,  if  an  object  b  of  type  t  is  accessible 
to  module  M,  then  every  t-operator  can  be  applied  by  M  to  b.  In  order 
to  facilitate  controlled  sharing  of  informatin,  it  has  been  recently 
proposed,  by  Jones,  Liskov,  Wulf  and  others  [Jon76,  Wul76] ,  to 
introduce  into  programming  languages  an  access-control  facility  which 
is  based  on  the  capability-based-protection  technique,  originally 
developed  for  operating-systems.  Here  are  the  essentials  of  this 


(*)We  will  use  the  terms  "procedure"  and  "operator"  interchangeably. 
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technique: 

I  A  sharable-object  (usually  allocated  on  the  heap)  can  be  accessed 
only  by  means  of  a  special  type  of  object  which  we  will  call  a  ticket, 
(the  more  common  name,  "capability",  would  not  be  appropriate  in  the 
context  of  this  paper) .  A  ticket  for  an  object  of  type  t  is 
essentially  a  pair  (b:t;r)  where  b  is  the  identifier  of  the  object, 
and  £  is  a  subset  of  a  finite  set  of  symbols 

rights(t)  =  {rl,...,rn} 

associated  with  the  type  t.  These  symbols  are  called  the  "rights"  with 
respect  to  t-objects.  Now,  the  point  is  that  the  set  of  operators 
which  can  be  applied  to  an  object,  depends  on  the  rights  contained  in 
the  ticket  which  is  used  to  address  the  object.  Thus,  a  ticket  (b: t; r) 
contained  in  module  H,  represents  the  privileges  that  M  has  to  object 
b.  (For  more  details  about  this  protection  scheme,  and  about  its 
incorporation  in  a  programming  language,  the  reader  is  referred  to 
[Jon76] .) 

In  this  paper  we  will  argue  that  tickets  are  not  always  sufficient 
for  the  representation  of  privileges.  In  particular,  they  are  not  very 
suitable  for  the  representation  of  value-dependent  privileges,  or  for 
the  control  of  interaction  between  objects.  In  order  to  make  up  for 
these  and  other  limitations  of  the  tickets  we  will  introduce  an  object 
called,  activator  to  serve  as  a  reference  to  an  operator,  and  to 
represent  privileges  with  respect  to  this  operator.  By  the  phrase 
"privileges  with  respect  to  an  operator"  we  mean,  loosely  speaking,  the 
conditions  under  which  the  operator,  addressed  by  the  given  activator, 
is  allowed  to  be  invoked.  The  essentials  of  a  protection  scheme  under 
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which  both  activators  and  ticket  are  used  for  the  representation  of 
privileges  is  introduced  in  the  next  section.  Being  based  primarily  on 
activators,  which  are  anchored  on  operators,  the  proposed  protection 
scheme  will  be  called  "operation-control"  (or  OC) ;  as  opposed  to  the 
term  "access-control"  (AC)  ,  for  the  protection  facility  based  on 
tickets,  which  are  anchored  on  objects.  The  two  facilities  are 
compared  in  section  3.  The  rationale  for  the  introduction  of 
activators  is  also  discussed  there. 

2£  THE  PROPOSED  PROTECTION  FACILITY 

2.1:  The  Activator 

Definition:  Let  o  be  an  operator  of  degree  k  (with  k 
formal-parameter).  An  activator  for  o,  or  an  “o-activator"  is  the 
following  construct: 


<o,  nl:pl, . . . ,nk:pk>  ♦  po 

Here  o  is  an  identifier  of  the  operator;  £i,  for  i=l,...,k  is  a 
condition  on  the  i-th  operand  of  o,  to  be  called  "operand-pattern"; 
and  po  is  a  condition  on  the  outcome  (result)  of  o  to  be  called 
"outcome-pattern"  (*)  (if  o  does  not  have  an  outcome,  then  the  part 
"■  >po"  does  not  appear  in  the  activator).  The  symbols  nl,...,nk  are 
names  of  the  respective  operands;  these  names  are  optional.  (A  more 
general  concept  of  activator  is  introduced  in  [Min76B,  section  3.6]). 

(*)  Whenever  we  would  not  wish  to  distiguish  between  these  two  types 
of  patterns,  we  will  use  the  term  "activation-pattern",  or  just 
"pattern",  for  either  of  them. 
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Now,  it  is  assumed  that  in  our  language,  an  operator  is  invoked  by 

the  phrase 

l 

A (ql , • • * ,qk) ,  ^ 

where  A  is  an  o-activator  for  some  operator  o,  and  qi  are  the 
actual-parameters  for  o.  This  phrase  is  to  be  evaluated  as 
follows:  First,  the  conditions  pi  of  the  activator  A  are  evaluated  on 
qi  for  i=l,...,k.  (Namely,  the  condition  pi  has  one  free  variable, 
which  is  to  be  bound  to  qi)  .  If  all  these  conditions  are  satisfied,  in 
which  case  we  will  say  that  "the  operands  match  the  respective  patterns 
of  A",  then  the  operator  o  is  applied  to  ql,...,qk.  Upon  return,  the 
outcome  (value)  of  o,  if  any,  is  checked.  If  it  does  not  match  the 
outcome-pattern  po  of  A,  it  will  not  be  communicated  to  the  program, 
and  an  error  condition  may  be  raised.  (This  checking,  or 
pattern-matching,  may  be  performed  either  at  run-time  or  at 
compile-time,  depending  on  the  structures  of  the  patterns  as  well  as  on 
other  properties  of  the  language) . 

Thus,  the  availability  of  a  specific  o-activator  to  a 
program-module  determines  the  conditions  under  which  the  operator  o  can 
be  invoked  by  this  module. 

Note  the  similarity  between  an  o-activator  and  the 

formal-parameters-specif ication  (or  FPS)  of  the  procedure  o:  Both 
determine  the  legal  set  of  operands  of  o.  There  is,  however,  an 
important  difference  between  these  two.  While  there  is  just  one  FPS 
per  operator,  we  will  see  below  that  there  may  be  several  different 
o-activators  for  the  same  operator  o.  In  this  sense,  our  activators, 
are  similar  to  the  "procedure-closure"  in  ELI  (Weg74J .  However,  unlike 
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the  Ell  procedure-closures,  our  activators  differ  from  each  other  not 
in  the  degree  of  binding  of  free  variables,  but  in  their  activation 
patterns. 

Before  committing  ourselves  to  any  specific  structure  of  the 
activation  patterns,  we  will  first  discuss  some  general  properties  of 
the  activators. 

Let  p  be  an  activation  pattern.  We  define  range (p)  to  be  the  set 
of  all  possible  objects  which  can  be  matched  to  p,  namely,  which 
satisfy  the  condition  p.  Let  p  and  p*  be  two  activation-patterns.  We 
will  say  that  p'  is  weaker  than  p  or,  equivalently,  p  is  stronger  than 
p',  if 

range  (p‘)  C  range (p) 

We  will  say  that  p*  is  strictly  weaker  than  p  if 

range(p')C  range(p) 

A  pattern  p*  which  is  weaker  than  p  will  also  be  referred  to  as  a 
reduction  of  g. 

Let  A  be  an  activator  of  order  k.  We  define  range (A)  to  be  the 
set  of  all  possible  (k+1) -tuples  (ql, . . . ,qk,qo)  of  objects,  such  that 
qi  matches  the  activation  patterns  (or  satisfies  the  condition)  pi,  for 
1*1,... ,k,  and  for  i=o. 

Let  A  and  A*  be  two  o-activators  for  a  given  operator  o.  We  will 
say  that  A'  is  weaker  than  A  (or,  equivalently,  A  is  stronger  than  A’) 

iff 
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range  (A1  )g  range  (A)  . 

We  will  say  that  A'  is  strictly  weaker  than  A  iff 

range  (A' )C  range  (A), 

such  an  A’  will  also  be  called  a  reduction  of  A.  It  is  clear  that  this 
last  relation  is  satisfied  between  A  and  A'  iff  all  the 
activation-patterns  of  A'  are  weaker  than  the  corresponding  patterns  of 
A,  and  at  least  one  of  the  patterns  of  A*  is  strictly  weaker  than  that 
Of  A. 

As  to  the  generation  of  activatorsf  the  following  is  assumed:  A 

new  activator  can  be  generated  in  the  following  two  ways: 

a)  When  a  new  operator  o  is  created ,  an  o-activator  is  generated 

with  it.  It  will  be  called  the  primary  o-activator. 

•*> 

b)  Given  an  activator  A,  one  can  generate  from  it  an  activator 
A'  which  is  weaker  than,  or  equal  to,  A.  A1  will  be  called  a 
derivative  of  A. 

The  following  properties  of  the  activators  follow  immediately  from  the 
above : 

a)  The  set  of  all  o-activators,  for  a  given  operator  o,  is 
partially  ordered  with  respect  to  the  relation  "stronger". 

b)  Every  activator  is  stronger  then  all  its  derivatives 

c)  The  primary  o-activator  is  the  strongest  o-activator. 

Note  that  the  generation  of  new  activators,  and  their  distribution 
among  the  various  modules  of  a  program,  may  be  performed:  either  at 
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comp lie- time  or  at  run-time  depending  upon  the  general  architecture  of 
the  host  language.  In  the  former  case,  activators  are  declared.  They 
serve  primarily  as  a  self  imposed  restriction,  on  the  part  of  die 
programmer,  as  to  the  use  which  he  intends  to  make  of  the  operator  in  a 
specific  module.  In  the  latter  case,  one  would  have  “activator-values" 
which  can  be  stored  dynamically  in  "activator-variables",  much  in  the 
same  way  as  some  languages  have  procedure-values  and 
procedure-variables.  One  would  also  need  special  operators  which  can 
generate  a  derivative  of  a  given  activator,  and  transport  activators 
from  one  place  to  another,  at  run-time. 

2.2.  The  Activation  Patterns 

As  defined  above,  an  activation  pattern  pi  is  a  condition  which 
must  be  satisfied  by  an  object,  which  is  either  the  i-th  operand,  when 
i*l,...,k;  or  the  outcome  of  the  operation,  when  i=0.  For  the  most 
parts  there  will  be  no  need  to  distinguish  between  these  two  cases,  and 
we  will  be  talking  simply  about  an  "activation-pattern"  p  and  the 
object  which  matches  it.  Whenever  necessary,  however,  we  will 
distinguish  explicitly  between  an  "operand-pattern"  and  an 
"outcome-pattern".  We  will  now  describe  a  specific  structure  of 
activation  patterns. 

An  activation  pattern  p,  to  be  denoted  by 

[I jR;V] 

is  a  conjunction  of  the  following  three  predicates,  to  be  called  the 
components  (sub-patterns)  of  p: 
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I  -  the  identity-based  pattern,  is  a  condition  on  the  type  and 
identity  of  an  object  to  be  matched  with  it. 

R  -  the  pr ivilege-based  pattern,  is  a  condition  on  the 

privileges,  or  "rights",  represented  by  the  operand-ticket. 
(This  sub-pattern  is  applicable  only  if  the  operand  is  a 
sharable  object) . 

V  -  the  value-based  pattern,  is  a  condition  on  the  value,  or  the 
state,  of  the  operand  itself. 

The  only  mandatory  part  of  p  is  I.  Each  of  the  other  components  may  be 
empty,  in  which  case  it  will  be  assumed  to  be  identically  TRUE.  The 
reduction  of  the  pattern  p,  namely,  the  reduction  of  range (p) ,  is 
performed  by  a  reduction  of  at  least  one  of  its  subpatterns. 

We  will  now  discuss  the  structure  of  each  of  these  three 
sub-patterns,  and  the  ways  by  which  they  can  be  reduced. 


2.2.1  Identity-based  patterns! 


I,  which  is  the  only  mandatory 


component  of  a  pattern,  has  one  of  the  following  two  forms, 
t  -  which  matches  any  object  of  type  t. 

b  -  which  matches  only  a  specific  object  b  of  type  t,  b  being  an 
object- identif ier .  This  form  is  applicable  only  when  t  is  a 
sharable  type  and  only  in  the  case  of  operand-pattern. 

A  subpattern  t  can  be  reduced  in  two  ways: 

a)  It  can  be  changed  into  b,  where  b  is  an  identifier  of  a 
specific  object  of  type  t. 


r 


Page  12 


b)  If  there  is  a  type  t'  such  that  t  includes  t' ,  then  t  can  be 
changed  to  t',  ("type-inclusion"  exists  in  a  number  of 
languages,  for  example  in  Simula  [Dah72] .  "Inclusion"  in 
meant  here  in  its  set  theoretical  sense) . 

The  sub-pattern  b  connot  be  reduced  any  further. 

The  type  t,  identified  by  I,  determines  the  structure  of  the  other 
two  components  of  the  pattern  which  will  sometimes  be  denoted  by  V(t) 
and  R(t) . 


2.2.2.  Value-based  patterns;  V,  which  is  the  third  component  of  a 
pattern,  is  a  condition  on  the  value  of  the  operand.  Although  we 
consider  value-dependency  to  be  a  vital  aspect  of  protection,  one 
cannot  always  expect  to  be  able  to  base  the  decision  as  to  the  legality 
of  an  operation  on  the  value  of  an  arbitrary  attribute  of  an  object. 
This  is  due  to  the  following  reasons: 

a)  It  happens  that  an  attribute  of  an  object  is  not  directly 
observable.  Such  are  the  items  stored  inside  a  stack,  for 
example. 

b)  It  may  happen,  in  certain  types  of  objects,  that  the  mere  act 
of  observation  of  an  attribute  of  an  object  introduces  a 
change  in  the  object  itself.  As  an  example  of  this  "quantum 
mechanical  effect",  the  only  way  td  observe  the  top  of  a 
stack  may  be  to  pop  it  up.  Obviously,  we  cannot  base  our 
pattern  matching  on  such  a  "volatile  attribute". 

For  these,  and  other  reasons  which  include  efficiency,  we  now  introduce 
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the  notion  of  "facade"; 

The  component  V  (or  rather  V(t))  of  a  pattern,  can  depend  only  on 
a  set  of  attributes,  called  the  facade (t) ,  which  are  explicitly 
declared  (as  part  of  the  type-definition)  to  be  useable  for  this 
purpose. In  particular,  for  a  given  type  t,  if  facade (t)  is  empty  then 
V(t)  must  also  be  empty.  By  convention,  the  facade  of  a  primitive 
scalar  type  ,  such  as  real  and  integer ,  will  be  its  value.  We  are 
ready  now  for  the  definition  of  the  functional  form  of  V. 

V ( t)  is  a  conjunction  vl&v2&. . .&vn,  where  each  vi  is  an  arbitrary 
predicate  over  the  set  of  attributes  in  facade (t)  of  the  operand. 

The  reason  for  the  conjunctive  form  of  V  is  that  it  allows  the 
following  simple  reduction  technique:  V  ^s  reduced  by  appending  a 
conjunct  to  it. 

•m 

One  may  want  to  impose  various  additional  restrictions  on  the 
functional  form  of  V,  for  efficiency  reasons.  Such  restrictions  will 
not  concern  us  here. 

Example  1:  Let  doc  be  a  type  of  sharable  objects  which  carries 
documents  in  a  military  information  system.  Suppose  that  a  document  is 
represented  by  a  triple:  (data:text,  security: integer,  cat:text) , 
where  the  phrase  data:text,  for  example,  refers  to  an  attribute  called 
"data"  of  type  "text".  Here,  "data"  stands  for  the  body  of  the 
document,  while  "security"  and  "cat"  are  the  security-class  and  the 
category  associated  with  the  document.  The  latter  two  are  the 
traditional  security  parameters  in  military  establishments,  [Wei  69]. 
In  order  to  use  these  attributes  for  protection  in  our  system,  we 
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define: 

facade (doc)  =  {security: integer ,  cat:text} 

Now,  let  read  be  a  doc-operator  which,  when  applied  to  a  document 
displays  its  contents.  Suppose  that  the  primary  read-activator  is 

READ  =  <read,  [doc]>. 

which  can  be  applied  to  any  documents  The  following  derivatives  of  READ 
are  less  powerfull:  The  activator 

READl  =  <read,  [doc;  ; cat* "navy"]  > 

can  be  used  to  read  any  Navy-document.  (Note  that  the  extra  semicolon 
in  READl  indicates  a  missing  R  part  in  the  pattern) .  The  following 
reduced  derivative  of  READl: 

READl 1  *  Cread,  [doc;  ;cat=“Navy“  &  security  <  3]  > 

can  be  used  to  read  only  Navy  documents  whose  security  level  is  not 
higher  than  3.  Finally,  the  activator 

READl 2  =  Cread,  [d;  ;cat="navy“] > 

can  be  used  to  read  a  specific  document  d,  provided  that  it  is  a 
Navy-document.  Of  course,  a  module  may  have  access  to  several 
read-activators  ,  which  would  allow  it  to  read  several  such  subsets  of 
documents.  Note  however,  that  the  availability  of  an  activator  is,  in 
itself,  not  sufficient  to  read  any  specific  document.  For  this  one  has 
to  have  tickets  for  the  appropriate  documents. 

2.2.3:  Privilege-based  patterns: 

To  support  the  type  of  access-control  mentioned  in  the  introduction. 
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the  remaining  component  of  the  activation  pattern,  R,  is  a  codition  on 
the  rights  which  are  contained  in  the  operand-ticket.  More 
^♦specif  ically,  let  the  type  t  identified  by  the  I-coponent  of  the 
pattern  be  a  sharable  type,  then  R  (or  R(t)  )  has  the  general  structure 

R  *  sl&s2&. . .&sk 

where  each  si  is  a  right  with  respect  to  type  t,  i.e.  all  si  are 
members  of  rights(t) .  As  to  the  interpretation  of  this  sub-pattern,  we 
will  have  to  distinguish  between  the  case  of  an  operand-pattern  and 
that  of  an  outcome-pattern,  starting  with  the  former. 

Consider  the  operand-pattern 

p  *  [I;  sl&s2&. . .&sk;  V] 

For  an  operand  to  be  matched  to  p,  it  must  be  represented  by  a  ticket 


c  ■  (bit;  r) 


where  b  and  t  satisfy  the  sub-patterns  I  and  V,  and  £  includes  all  the 
rights  sl,...,sk  which  appear  in  p.  Thus  R  is  a  set  of  rights  which 
are  required  from  the  matching  ticket.  The  reduction  of  the 
sub-pattern  R  is  performed  by  adding  rights  to  it,  thus  imposing 
stronger  requirements  on  the  corresponding  operand. 

As  an  example,  consider  again  our  document  case.  Let 


rights(doc)  =  {observe, update} 


We  will  now  assume  that  there  are  two  doc-operators:  read  and 

update.  The  primary-activator  of  read  is  now 
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READ  =  <read,  [doc ; observe! > 
that  of  update  is 

UPDATE  3  <update,  [doc; update] , [text] > 

where  the  second  operand,  which  must  be  a  text-object,  is  to  be 
inserted  into  the  document.  Consider  a  module  M  which  has  these 
two  activators  in  its  domain,  together  with  the  tickets: 

(dl:doc;  ALL),  (d2:doc;  observe),  (d3:doc) 

The  document  dl  can  be  both  observed  and  updated  by  M;  d2  can 
be  only  observed,  because  it  cannot  be  matched  to  the  first 
activation  pattern  of  UPDATE;  and  the  document  d3,  which  has  no 
rights  in  it,  can  be  neither  read  nor  updated  by. M. 

Note  that  the  above  activators  may  be  reduced  as  before. 
For  example,  the  following  derivative  of  READ 

READl  3  <read,  [doc;observe;security<2]  > 
allows  its  holder  to  read  any  document  whose  security  level  is 
smaller  than  2,  provided  that  he  has  a  ticket  with  the  "observe" 
right  in  it. 

Next,  let  us  discuss  the  case  of  outcome-patterns.  Consider  the 
activator 

A  »  <...>  — — ►  [t;  sl&s2&. .  .&sk;  V] 
where  t  is  a  sharable  type. 

The  outcome-pattern  of  A  means,  first,  that  the  outcome  of  an  operation 
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A(ql,...,qn)  must  be  a  ticket  c  =  (b:t;  r)  of  some  object  b  of  type  t, 
where  the  object  satisfies  condition  V.  Secondly,  the  set  of  rights 
{sl,...,sk}  acts  as  a  filter  on  the  returned  rights,  r(c),  in  the 
following  way:  Any  right  returned  by  the  operator  o  which  is  not 
represented  in  {sl,...,sk}  would  be  erased  from  r(c).  Thus,  R  serves 
as  an  upper  limit  for  the  rights  which  might  be  returned  with  the 
outcome  of  A (ql , . . . ,qn) .  The  reason  for  this  interpretation  of  R  is 
explained  in  [Min76B] .  (A  note:  it  is  possible  to  have  a  more  strict 
interpretation  of  the  outcome-pattern,  requiring  that  exactly  the 


rights  (sl,...,skj  are  present  in  the  outcome-ticket. 


Such 


interpretation  would  facilitate  compile-time  checking  but  it  has  some 
disadvantages,  not  to  be  discussed  here) . 

The  reduction  of  the  R  component  of  an  outcome-pattern  is 

performed  by  deleting  rights  from  the  sequence  sl&s2& . . .&sk.  This  has 

the  effect  of  reducing  the  set  of  possible  rights  which  can  be 

associated  with  tickets  returned  as  an  outcome  of  a  given  operation. 
(Note  the  contrast  between  the  reduction  of  operand-patterns  and  that 
of  the  outcome-pattern) . 

As  an  example,  let  gen-doc  be  an  operator  which  generatesa 
documents.  Let  its  primary  activator  be 

GEN-DOC  ■  <gen-doc,  content: [text] , security: [integer J , 

cat: [text]  >  — [docyupdate, observe] 

The  three  operands  of  gen-doc  determine  the  initial  state  of  the 

generated  document:  its  content,  security-level  and  category.  A 

module  which  has  this  activator  can  generate  documents  with  arbitrary 
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security-level  and  category,  and  gets  a  ticket  for  the  generated  object 
with  all  its  possible  rights.  Suppose  now  that  a  certain  module  M  is 
to  be  allowed  to  generate  only  documents  with  the  category  ,lnavy" ,  and 
that  these  documents  should  be  unchangeable.  For  this  purpose  M  should 
have  the  following  reduction  of  GEN-DOC. 

GEN-DOC-1  =  <gen-doc, ... ,cat: [text; ; value  =  "navy"] >  — »  [doc;observe] 

Note  that  documents  generated  by  GEN-DOC-1  can  never  be  changed  because 
there  can  be  no  tickets  with  the  "update"  right  for  them.  (This 
observation  is  based  on  the  assumption  that  there  is  no  way  to  add 
rights  to  a  ticket,  as  it  is  the  case  under  the  protection  scheme 
proposed  in  [Min76b] ,  and  it  is  almost  the  caseunder  the  scheme 
proposed  in  [Jon76] ) . 

2.3:  The  control-objects 

•  •  ^ 

We  can  summerize  the  proposed  scheme  as  follows:  the  dispersion 
of  privileges  among  the  various  modules  of  a  program  is  represented  by 
the  distribution  of  two  types  of  objects,  the  activators  and  the 
tickets.  We  will  refer  to  both  as' control-objects.  There  is  a  certain 
symmetry  between  these  two  types  of  control-objects:  Just  as  a  ticket 
represents  privileges  with  respect  to  an  object,  an  activator 
represents  privileges  with  respect  to  an  operator.  Although  the  term 
•privilege"  has  different  conotations  in  the  two  cases. 

Note  the  complementary  nature  of  the  activators  and  the 
tickets:  An  activator  is  in  a  sense,  the  means  which  one  has  to  carry 
out  an  operation,  while  a  ticket  represents  the  opportunity  to  apply  an 
operator  to  a  specific  object.  One  need  both  in  order  to  actuly 
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perform  an  action.  For  example,  the  activator 

<read,  [doc; ;cat="navy"]  >  is  the  means  to  read  Navy  documents,  but 
in  order  to  read  any  specific  document,  one  must  have  an  access  to  it, 
via  a  ticket,  in  our  case. 

Since  the  distribution  of  the  control-objects  determines  what 
every  module  of  a  program  can  do,  it  is  vital  to  have  a  tight  control 
over  the  generation  and  transport  of  these  objects.  The  essentials  of 
such  controls  are  discussed  in  [Min76b] ,  but  they  are  yet  to  be  adapted 
to  a  programming  language  environment. 


3_s.  DISCUSSION 

There  are  two  dimensions  along  which  a  protection  facility  should 
be  evaluated:  The  ease  of  its  enforcement,  and  its  contribution  to  our 
ability  to  impose  a  desired  policy.  (By  the  term  "policy"  we  mean  a 
certain  distribution  of  privileges  among  the  various  modules  of  a 
program) .  In  order  to  have  a  specific  frame  of  reference  for  our 
discussion  we  will  compare  the  operation-control  (OC)  facility  in  which 
both  activators  and  tickets  are  used  for  the  representation  of 
privileges,  with  the  access-control  (AC)  facility  which  is  based 
primarily  on  tickets. 

3.1:  The  enforcement  mechanism 

The  enforcement  mechanism  which  is  necessary  for  the  OC  facility 
is  essentially  identical  to  the  checking  of  procedure-parameters 
performed  by  most  languages.  The  only  difference  is  that  the 
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conditions  built  into  an  activator  may  be  more  complex  than  those 
allowed  in  the  formal-parameter-specifications  of  a  procedure.  In 
particular,  we  are  allowing  for  value-dependent  conditions,  which  in 
most  cases  could  not  be  evaluated  at  compile  time.  Obviously,  there  is 
a  price  to  be  payed  for  the  evaluation  of  more  complex  conditions. 
However,  this  price  is  incremental.  In  particular,  the  enforcement 
mechanism  which  is  needed  for  activators  which  have  no  value-dependent 
patterns  is  no  different  than  the  enforcement  mechanism  needed  to 
support  the  AC  facility. 

3-2:  Why  activators? 

In  this  section  we  will  discuss  the  limitations  of  tickets  alluded 
to  in  the  introduction.  We  will  also  see  how  the  use  of  activators 
makes  up  for  these  limitations. 

3.2.1:  interactions  and  their  control :  The  privileges  which  are 
represented  by  a  ticket  determine  which  operators  can  be  applied  to  the 
object  addressed  by  it.  This,  however,  is  not  always  sufficient  to 
characterize  all  possible  manipulations  of  objects:  There  may  be 
operators  which  involve  several  objects,  and  which  cannot  be  decomposed 
into  a  sequence  of  legal  operations  on  the  individual  objects.  Such  an 
operator  will  be  called  an  interaction.  Now,  it  has  been  . shown  in 
[Min76b]  that  in  a  system  with  interactins  there  are  policies  which 
cannot  be  imposed  purely  by  means  of  tickets.  To  illustrate  this 
difficulty  consider  the  following  example: 
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Let  appoint (e,  j)  be  an  interaction  defined  in  a  corporate 
information-system,  which  appoints  employee  e  to  job  j.  Let  El  and  E2 
^>e  two  sets  of  employees,  and  let  Jl,  J2  be  sets  of  jobs.  Suppose  that 
a  module  N  is  to  be  allowed  to  appoint  only  employees  from  El  to  jobs 
from  Jl,  and  employees  for  E2  to  jobs  from  J2.  suppose  also  that  this 
restriction  is  specific  to  M  and  does  not  necessarily  apply  to  other 
modules.  A  moment  of  reflection  would  '  reveal  the  difficulty  of 
conferring  exactly  this  privilege  on  M  purely  by  means  of  tickets. 
There  is  no  such  difficulty  under  the  OC  scheme,  however.  It  would  be 
sufficient  to  give  M  the  two  activators. 

<appoint,  [employee; ; vel] ,  [job;;vjl]  > 

<appoint,  [employee; ;ve2] ,  [job;;vj2]  > 

provided  that  vel  and  ve2  are  predicates  which  are  satisfied  only  by 
members  of  the  sets  El  and  E2  respectively.  Similarly,  vjl  and  vj2 
should  ientify  Jl  and  J2  respectively. 

3.2.2:  Value-dependent  restrictions:  The  access-control  protection 
scheme  was  never  intended  for  value-dependent  restrictions  [Jon75] . 
Indeed,  the  only  way  to  impose  such  restrictions,  strictly  by  means  of 
access  control,  is  by  a  suitable  value-dependent  distribution  of 
tickets  (see  [Min76b] ) .  As  we  will  demonstrate  later  by  an  axample, 
such  an  implementation  is  very  costly  and  error-prone  ,  particularly 
because  this  distribution  must  be  changed  with  the  values  on  which  the 
policy  depends.  Of  course,  value  dependency  is  very  natural  under  our 
OC  scheme,  as  was  demonstrated  by  the  examples  in  section  2,  and  will 
be  illustrated  again  by  another  example, below. 
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3.3:  The  complementarity  of  tickets  and  activators . 

The  rationale  for  using  activators  is  not  just  to  make  up  for 
limitations  of  the  tickets.  As  was  mentiond  in  section  2.3 ,  the 
representation  of  authority  structures  requires  two  types  of 
control-objects  ,  to  represent  "means-  and  "opportunities",  both  of 
which  are  necessary  in  order  to  perform  an  action.  These  complementary 
roles  are  played  by  the  activators  and  by  the  tickets. 


3.4  An  example: 


In  order  to  compare  our  operation-control  with  the  access-control 
scheme,  we  will  now  discuss  the  implementation  of  a  specific  policy  by 
means  of  both.  The  example  to  be  discussed  is  a  generalization  of  an 
example  which  has  been  used  in  [Jon75]  to  demonstrate  the  featurs  of 
the  AC  scheme.  Here  we  will  show  that  the  same  situation  can  be 
handled  much  easier  and  more  efficiently  under  the  OC  scheme. 

Let  memo  be  a  type  of  objects  which  carry  memoranda.  Suppose  that 
in  addition  to  the  text  itself,  which  can  be  retrieved  by  the  operator 
read,  every  memo-object  has  a  set  of  attributes 

X  *  {xl, . . . ,xn} 

associated  with  it,  where  all  xi  are  boolean  variables.  We  will  say 
that  a  memo  m  "satisfies  a  certain  attribute  xi"  if  xi(m)  =  TRUE. 
Suppose  also  that  for  every  subject (*)  S  there  is  a  set 
Y(S)  *  {yl, . . . ,yk}cx  of  memo  attributes  which  determine  the  set  of 


(*) Following  the  terminology  used  in  the  operating  system  protection 
literature,  we  will  use  here  the  term  "subject"  as  a  synonyme  for  a 
"module" . 
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memos  which  should  be  readable  by  S,  according  to  the  following  policy: 
S  should  be  allowed  to  read  all  memos ,  and  only  such ,  which  satisfy  all 
li  in  Y (S) . 

An  PC- implementation  of  this  policy  is  the  following. 

Let 

facade (memo)  -  {xl,...,xn} 
rights (memo)  =  NULL 
and  let  the  primary  read-activator  be 

READ  ®  <read, [memo] > 

Suppose  that  a  subject  S  is  given  only  the  following  reduction  of  READ. 

READl  =  Cread, [memo; . ;  yl& , . . . , &yk] > 

Suppose  also  that  the  set  of  tickets  { (m:memo) } ,  one  for  each 
memo-object  in  the  system,  is  stored  on  a  file  dir  from  which  all 
subjects  can  copy  tickets  .  It  is  obvious  that  the  desired  policy  is 
satisfied  under  these  conditions. 

The  salient  feature  of  this  implementation  is  that  the  various 
subjects  have  effectively  different  "power-  with  respect  to 
memo-objects,  due  to  the  different  read-activators  in  their  domains. 
That  is  why  they  can  safely  share  the  same  set  of  tickets,  contained  in 
file  dir,  and  still  have  different  privileges.  As  we  will  see  next, 
the  situation  is  quite  different  in  the  access-control  case. 


Under  the  AC  scheme,  we  assume  that  the  operator  read  demands  that 
the  right  "read"  is  in  the  ope rand- ticket.  Since  all  subjects  involved 
must  have  the  right  to  invoke  read,  the  difference  between  the  subjects 
can  only  be  in  terms  of  the  memo-tickets,  each  with  the  "read"  right. 
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which  are  available  to  them.  Thus,  the  desired  policy  can  be 
established  as  follows: 

For  a  given  memo-object  m,  let: 

Z (m)  =  {zl, . . , ,zj}  £  X 

be  the  set  of  boolean  attributes  satisfied  by  m.  Let  target (m)  be  the 
set  of  subjects  S  such  that  for  each  of  them  Y(S)C  Z  (m)  .  This  is 
exactly  the  set  of  subjects  which  by  our  policy  should  be  allowed  to 
read  m.  Therefore,  the  ticket  (m:memo;read)  should  be  available  to 
these  subjects  and  to  none  other.  In  order  to  establish  such  a 
distribution  of  tickets,  we  suppose  that  every  subject  S  in  our  system 
has  a  directory  file,  dir(S),  which  is  readable  only  by  him.  Whenever 
a  new  memo-object  m  is  created,  a  non-copyable  ticket  (m:memo, read) 
should  be  stored  in  dir(S)  for  every  S  in  target (m) ,  and  in  nowhere 
else.  This  is  essentially  the  solution  given  by  Jones  and  Wolf  to  a 
similar  problem  [Jon751 . 

Let  us  now  compare  these  two  implementations  of  our  policy,  along 
two  dimensions:  the  number  of  control-object,  which  are  needed  for  the 
implementation  of  the  policy,  and  the  coplexity  of  the  distribution  of 
these  objects. 

As  to  the  number  of  control  objects,  suppose  that  there  are  NS 
subjects  in  a  system  which  are  to  be  allowed  to  read  memos,  and  let 
there  be  M  memo-objects.  Let  K  be  the  average  number  of  subjects  which 
are  allowed  to  read  a  memo-object.  The  AC  implementation  requires  K*M 
memo-tickets  to  be  stored  in  the  system,  while  under  the 
0C- implementation  only  H  tickets  are  required. 
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Even  more  important  than  the  number  of  the  control  objects,  is  the 
complexity  of  their  distribution.  The  AC- implementation  requires  a 
very  specific  distribution  of  the  memo-tickets  among  the  NS  files 
dir(S).  This  distribution  of  tickets  is  itself  a  formidable  task. 
Moreover,  every  file  dir(S)  must  be  well  protected,  and  readable  by  the 
specified  subject  S  only. 

The  situation  under  the  OC  implementation  is  much  simpler:  Once 
the  NS  different  read-activators  are  correctly  distributed  among  the 
various  modules,  we  can  store  all  the  M  tickets  in  one  file,  which  is 
readable  by  everybody  and  does  not  have  to  be  especially  protected. 
This  is  obviously  much  less  complex  than  under  the  AC- implementation. 
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ABSTRACT 


The  access-control  authorization  scheme,  which  is  being  used  for  the 
'  protection  of  operating  systems,  is  found  to  be  inadequate  in  other  areas,  such 
as  in  databases  and  information  systems.  A  new  authorization  scheme,  which  is  a 
natural  extension  of  access-control,  is  proposed.  The  new  scheme,  which  is 
called  "operation-control",  is  shown  to  be  superior  to  the  access-control  scheme 
In  a  number  of  ways.  In  particular:  it  facilitates  more  natural  and  efficient 
representations  of  policies,  particularly  the  type  of  complex  policies  which 
appear  in  Information  systems;  it  facilitates  enforcement  by  compile-tine 
validation  due  to  a  greated  stability  of  authority-states;  and  it  reduces  the 
need  for  revocation. 


-  i 


€> 


Say  words  and  phrases:  protection,  access-control,  operation-control,  authorization 
operating  systems,  information  systems.  '  .  - 


a  Utagories:  4.29,  4.33,  4.35 


Pass  3 


vy 


TABLE  OF  CONTENTS 


1 :  Introduction 

2:  The  access- control  (AC)  approach  to  protection 

Jt  The  operation-control  (OC)  scheme 

3.1:  Terminology  and  conventions 
3.2:  Activators  and  the  enforcement  mechanism 
3.3:  The  activation  patterns 
3.4:  Control  over  the  generation  of  objects 
3.5:  The  control-objects:  their  role  and  behavior 
3*6:  The  structure  of  domains  and  their  dynamic  behavior 
3.7:  The  global  condition  of  activators 
3.8:  On  the  kernel  of  the  protection  mechanism 
4.  Discussion 

4.1:  Conceptual  simplicity 
4.2:  Expressive  power 
4.3:  Efficiency 


5; 


Conclusion 


Authorization  in  computer  systems  is  a  discipline  under  which  an  action  on 
the  system  can  be  carried  out  by  a  user  t  or  by  one  of  the  modules  of  the 
system,  only  if  the  actor  is  authorized  to  perform  this  action.  Such  a 
discipline  is  necessary  for  the  protection  of  the  security  and  of  the  semantic 
integrity  of  systems. 

Most  current  protection  techniques  are  based  on  the  so  called 
aecess-control  approach  to  authorization.  This  approach  has  been  developed  by 
Lampson  [Lam71],  Graham  and  Denning  [gra72],  Vulf  and  Jones  [Wul71>]t  and  others, 
mostly  in  the  context  of  operating  systems,  and  it  enjoys  a  considerable  degree 
of  success  in  this  area.  Unfortunately,  however,  this  success  has  not  been 
matched  in  other  areas,  such  as  databases  and  information-systems.  It  is  our 
contention  that  this  failure  is  due  to  some  fundamental  limitations  of 
access-control  as  a  scheme  for  representation  of  authority-structures.  These 
limitations  are  discussed  in  section  2.  A  generalization  of  the  access-control 
authorization  scheme  is  suggested  in  section  3,  and  its  merits  are  discussed  in 
section  4. 


ZS.  THE  ACCESS-CONTROL  (AC)  APPROACH  10  AUTHORIZATION 

The  access-control  approach  to  protection  and  authorization  is  well 
documented  in  the  literature.  In  particular,  the  reader  is  refered  to  the 
excellent  review  articles  by  Saltzer  [Sal75]  and  Linden  [Lin76].  Here  we  will 
outline  only  the  essential  features  of  this  approach,  and  we  will  discuss  some 


of  lta  limitations 


The  system  to  be  protected  is  formally  viewed  as  a  four- tuple  (B,0,J,U), 
where:  B  is  a  set  of  objects:  0  is  a  set  of  operators:  J  is  a  set  of 
subjects,  which  are  the  actors  that  actually  apply  operators  to  objects,  and  are 
thus  responsible  for  the  dynamic  behavior  of  the  system;  and  (I  is  the 
authoritv-state  of  the  system.  The  authority-state  is  formally  defined  as  a  set 
((S,b,o)},  where  a  triple  (S,b,o)  is  the  permission  for  subject  £,which  belongs 
to  J,  to  apply  operator  £  to  object  £.  In  other  words,  (S,b,o)  is  a  permission 
for  S  to  have  "access  £  to  object  £".  Of  course,  the  system  must  be  supported 
by  an  enforcement  mechanism  which  guarantees  that  only  operations  which  are 
permitted  by  the  authority-state  U  are  carried  out. 

There  are  a  number  of  ways  to  represent  the  set  of  permissions  {(S,b,o)}. 
A  method  which  is  particularly  relevant  to  this  paper  is  called  the 
capabllitv-based-protection  [Wul74,  Lam76].  Under  this  version  of  the  AC-scheme 
the  authority-state  of  a  system  is  represented  by  a  distribution  of  special 
"control-objects"  which  we  call  tickets.  A  ticket  is  a  pair  c=(b;r)  ,  where  £ 
.is  an  identifier  of  an  object,  and  £  is  a  subset  of  a  finite  set  of  symbols, 
called  "rights"  (or  access-rights),  which  identify,  in  some  way,  the  operators 
that  can  be  applied  to  object  £.  That  Is  to  say,  the  subject  S  who  possesses 
the  ticket  (b;r)  is  allowed  to  apply  to  b  the  operators  identified  by  r.  The 
generation  and  transport  of  tickets  is  tightly  controlled  so  that  the  mere  fact 
that  a  subject  S  has  the  ticket  cs(b;r)  is  taken  as  (incontestable  proof  that  S 
is  authorized  to  have  the  specified  access  rights  to  object  b. 

Thus,  under  the  AC-scheme  (or,  rather,  under  the  capability-based*  version 

(*)  The  phrase  "capability-based"  used  for  this  version  of  the  access-control 
protection  is  appropriate,  even  though  we  are  using  the  term  "ticket"  for  what 
is  usually  called  "capability",  because  the  set  of  tickets  owned  by  a  given 
subject  determines  his  capabilities  with  respect  to  the  system.  (In  this  paper 
the  term  capability  will  be  used  in  its  colloquial  sense). 


Of  It)  tbo  tickets  are  used  as  the  elementary  building  blocks  of 
author!  tv-structures.  kind  of  "elementary-particles"  of  authority. 
Unfortunately,  tickets  are  not  suitable  to  serve  as  the  only  elementary 
particles  of  authority,  for  a  number  of  reasons: 

first,  every  ticket  represents  privileges  with  respect  to  a  specific 
object,  the  one  addressed  by  it.  These  privileges  are  independent  of  the  value 
(or  state)  of  the  object.  The  problem  is  that  authority  structures  are 
frequently  based  on  the  value  of  the  objects  Involved,  and  are  independent  of 
their  Identity.  To  demonstrate  the  difficulty  here,  consider  the  following 
example.  When  a  highway  patrolman  is  sent  to  his  duty  he  has  to  be  given  the 
authority  to  cite  traffic  violators.  This  authority  is  not  given  to  him  in  the 
form  of  tickets,  one  for  each  violator.  Indeed,  the  patrolman's  authority 
cannot  be  defined  in  this  form  because  at  the  time  that  the  patrolman  is  sent  to 
his  duty  the  traffic  violators  do  not  exist,  and  the  identity  of  the  future 
Violators  is  not  known,  so  that  it  is  Impossible  to  construct  individual  tickets 
for  the  violators  at  that  time.  The  point  is  that  the  patrolman's  authority  has 
to  do  with  the  behavior  of  motorists,  not  their  identity.  Tickets  are  too 
specific  for  this  purpose,  and  at  the  same  time,  they  are  not  sensitive  enough, 
being  independent  of  the  properties  (values)  of  the  objects  addressed  by  them. 

Another  problem  with  tickets  is  due  to  the  unit  of  activity  which  they  are 
designed  to  authorize.  Every  ticket  represents  a  permission  to  apply  certain 
operators  to  the  object  addressed  by  it.  However,  the  activity  of  a  subject  may 
not  be  expressible  purely  in  terms  of  operations  on  Individual  objects.  One  may 
have  to  use  interactions  between  objects,  where  by  "interaction"  we  mean  an 
operation  which  involves  several  objects,  and  which  cannot  be  decomposed  into  a 
sequence  of  legal  unary  operators  on  the  individual  objects.  The  problem  is  how 


to  express  privileges  with  respect  to  an  interaction  purely  by  aeans  of  tickets, 
which  represent  permissions  to  perform  operations  on  individual  objects.  When, 
the  Interaction  itself  cannot  be  decomposed  into  such  operations.  (This 
difficulty  will  be  demonstrated  by  an  example  in  section  4.2.2). 

Our  conclusion  from  these  observations  is  that  there  is  a  need  for  a  new 
type  of  control  object  which  can  authorize  directly  interactions  between 
objects,  and  which  would  not  be  based  exclusively  on  the  identity  of  the  objects 
involved  in  operations.  Such  a  control-object,  which  we  call  an  activator,  is 
the  basis  for  the  protection  scheme  proposed  in  this  paper. 

3:  THE  OPERATION-CONTROL  tQCl  SCHEME 

The  protection  scheme  to  be  introduced  in  this  section  is 
"capability-based1*  in  the  sense  that  it  associates  with  every  subject  a  set  of 
control-objects  which  determine  its  capabilities.  However,  our  scheme  differs 
from  the  access-control  scheme  by  the  nature  of  these  control-objects.  In 
addition  to  the  tickets  which,  as  under  the  AC-scheme,  represent  privileges  with 
respect  to  objects,  we  have  control-objects  called  activators,  which  represent 
privileges  with  respect  to  operators,  in  the  following  sense:  Every  activator  A 
identifies  an  n-ary  operator  a  (for  nlO),  specifying  the  conditions  under 
which  SL  can  be  invoked  by  the  subject  who  possesses  A*  There  may  be  several 
such  activators  for  the  same  operator  At  which  may  impose  different 
pre-conditions  on  the  activation  of  At  representing  different  privileges  with 
respect  to  a*  We  are  using  the  name  operation  control  (OC)  for  this  scheme 
because  the  activators  possessed  by  a  subject  determine  directly  the  type  of 
operations  which  he  can  perform,  not  just  the  "accesses”  that  he  has  to  various 


objects. 


Terminology  gnl  Conventions 


to  set  up  the  stage  for  our  discussion  we  now  Introduce  our  Interpretation 
for  soae  well  known  terms  such  ss  object,  subject,  domain  and  type. 

ft. 1.1  Objects  and  their  types;  We  base  our  approach  towards  types  on  the 
type-concept  used  in  Hydra  t Jon75] ,  which  is  briefly  as  follows: 

The  set  of  all  objects  in  a  system  is  described  In  terms  of  the  three-level 
tree  in  Figure  1.  The  root  of  this  tree  is  a  primitive  and  unique  object  called 
"template” .  The  objects  at  the  second  level  are  instances  of  this  "template”, 
and  are  called  template-objects,  or  type-objects.  Each  of  these  type-objects, 
such  as  the  object  £,  serves  as  a  template  for  a  set  of  objects  in  the  third 
level,  which  are  said  to  be  "objects  of  type  t",  or  *t»objects".  A  template  t 
is  supposed  to  contain  the  structural  definition  of  all  its  instances. 

eeeeeeeeee 

•  Fig  1  • 


In  order  to  impose  some  behavioral  discipline  on  objects,  we  introduce  the 
concept  of  "ptotected  type".  This  is  a  type  i  for  which  there  is  a  fixed  set  of 
operators  (procedures)  which  have  the  exclusive  ability  to  manipulate  and 
observe  t-objects  directly.  He  will  say  that  such  an  operator  is  "privileged 
with  respect  to  t".  The  set  of  all  these  operators,  for  a  given  £,  is  denoted 
by  prlvllegedCt) .  Thus,  a  t-objeet  for  a  protected  type  t  can  be  manipulated 
either  directly,  from  within  one  of  the  prlvileged(t)  operators,  or  indirectly 
by  invoking  these  operators.  An  important  special  case  is  an  operator  which  is 
privileged  with  respect  to  only  one  type  t:  such  an  operator  will  be  called  a 
t-opcrator  .  (Note  that  the  existence  of  a  fixed  set  of  t-operators  is  the 


'-v  basis  for  tbs  notion  of  "abstract-data- type"  as  it  is  defined  in  CLU 
[Li 374]  (•)  ). 

3.1.2  Sharable  objects  and  their  tickets;  He  distinguish  between  two  broad 
classes  of  objects,  to  be  called  "sharable  objects"  and  "concrete  objects".  A 
concrete  object  is  one  which  is  physically  contained  in  one's  "domain" (••) .  For 
example,  the  Integer  7  and  the  symbol  "seven"  are  concrete  objects.  A  sharable 
object,  on  the  other  hand  is  not  contained  in  any  private  domain,  but  it  can  be 
shared,  or  accessed,  by  several  subjects,  by  means  of  a  concrete  object  called 
ticket  (which  is  essentially  identical  to  the  ticket  of  the  access-control 

•  /  <4 

scheme). 

With  every  type  t  of  sharable-ob j ects  we  associate  a  (possibly  empty)  set 
of  symbols: 

ClKhta(t)  »  (r1,...,rn) 

Bach  of  these  symbols,  ri,  will  be  called  a  "right"  with  respect  to  type  t. 


(•)  It  should  be  pointed  out  that  our  scheme  is  not  based  on  the  concept  of 
"privileged-operators".  It  is  the  other  way  around:  we  will  see  later  that 
privileged  operators  can  be  implemented  under  our  scheme.  This  concept  is  mentioned 
at  this  point  to  accomodate  some  of  our  examples  in  the  following  sections. 


(••)The  concept  of  domain  will  be  defined  later; 
see  it  as  the  workspace  of  some  user. 


for  the  moment  it  is  enough  to 
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A  ticket  £  for  an  object  A,  of  type  ±  is  defined  to  be  a  concrete  object 
which  will  be  denoted  by: 


e  ■  (b:t;  r) 

where  r,  or  r(c)(  is  a  subset  of  rights(t) .  If  a  given  right  ri  is  in  r(c)y 
we  will  say  that  "the  ticket  c  has  the  right  ri".  Since  the  content  of  a  ticket 
depends  on  its  £  component  we  will  use  the  phrase  t-ticket  to  identify  all 
tickets  which  address  t-objects.  A  t- ticket  which  has  all  its  possible  rights 
will  be  denoted  by  (b:t;  ALL).  Note  that  the  symbols  ri  have  been  called 
"rights*  in  anticipation  of  their  role  in  our  protection  scheme,  which  will  be 
discussed  later.  (Note:  the  *t"  part  of  £  signifies  that  &  is  the  identifier 
of  an  object  of  type  t.  Whenever  the  type  of  J i  can  be  understood  from  the 
oontext  we  will  use  the  simplified  notation  (b;r)  for  a  ticket.) 

In  general,  there  may  be  several  tickets  which  point  to  the  same  object  b. 
He  will  say  that  such  tickets  are  related .  Let  cl,  c2  be  two  related  tickets. 
He  will  say  that  cl  is  weaker,  or  less  permissive,  than  c2  if 

r(e1)<s  r(c2) 

Also,  we  will  say  that  cl  is  strictly  weaker  than  c 2  if 

Hoi)  e  r(c2) 

As  to  the  generation  and  manipulation  of  tickets,  the  following  is  assumed. 
Tickets  cannot  be  changed,  and  they  can  be  generated  only  in  the  following  two 

mays: 

a)  When  a  new  sharable  object  &  of  type  £  is  created,  a  ticket  for  it  is 
also  created,  with  all  of  riahts(t)  in  it.  This  ticket,  (b:t;  ALL), 
will  be  called  the  primary  ticket  of  object  b. 


b)  Given  a  ticket  £  It  nay  be  possible  to  generate  a  new  ticket  £* ,  which 
cannot  be  stronger  than  £.  Such  c* ,  which  addresses  the  same  object 
as  et  will  be  called  a  derivative  of  c.  (Later  we  will  see  when  It  Is 
actually  possible  to  generate  derivatives  of  a  given  ticket) . 

3.1.3  The  facade  of  ob.lects:  One  of  the  objectives  of  our  scheme  is  to  enable 
value-dependent  authorization.  However,  one  cannot  always  expect  to  be  able  to 
base  the  decision  as  to  the  legality  of  an  operation  on  the  value  of  all  the 
attributes  of  an  object.  This  is  due  to  the  following  reasons: 

a)  It  may  happen  that  an  attribute  of  an  object  is  not  directly 

observable.  As  an  example  consider  the  hidden  components  of 
"abstract- data- types" . 

b)  It  may  happen,  in  certain  types  of  objects,  that  the  mere  act  of 

observation  of  an  attribute  of  an  object  introduces  a  change  in  the 
object  itself.  An  example  of  this  "quantum  mechanical  effect",  is  a 
record  on  a  tape,  which  cannot  be  observed  without  repositioning  the 

tape. 

o)  One  may  not  want  to  allow  the  use  of  certain  attributes  for 

protection,  because  such  a  use  may  itself  reveal  confidential 

information  about  the  object. 

For  these,  and  other  reasons  which  include  efficiency,  we  now  introduce  the 
concept  of  the  "facade"  of  an  object,  -jhich  is  the  part  of  an  object  which  X& 
Maihlfi  for  protection  purposes.  More  formally,  with. every  type  £  we  associate 
the  set: 


fSoade(t) 
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which  is  the  set  of  attributes  of  t-objects  which  are  usable  for  authorization 
purposes.  By  convention,  the  facade  of  primitive  scalar  objects,  such  as  real 
aod  integer  numbers,  is  their  value. 

UUL  Subjects  and  their  domains:  A  computing  system  changes  in  time  in 
response  to  Instructions  submitted  to  a  processor  for  execution*,  where  an 
"instruct ion”  is  a  request  to  apply  a  specific  operator  to  a  specific  sequence 
of  operands,  tie  will  distinguish  between  two  types  of  instruction  sources: 

a)  An  external  source,  such  as  a  human  user  sitting  at  the  terminal . 

b)  An  Internal  source,  which  is  a  procedure  maintained  as  an  object  in 
the  system. 

One  Important  difference  between  these  two  types  of  instruction-sources  is  that 
an  external  source  is  totally  unpredicatable,  as  far  as  the  system  is 
concerned;  while  the  behavior  of  a  procedure  can  be  at  least  partially 
predicted  ahead  of  time. 

He  define  a  subject  to  be  a  pair 


(IKS.D) 

where  INS  is  an  instruction-source,  and  D  is  the  collection  of  objects  which  are 
directly  addressable  by  INS.  D  will  be  called  the  domain  of  S.  He  will  later 
see  that  the  domain  of  a  subject  determines  its  capabilities,  and  also  serves  as 
its  workspace. 


•For  simplicity,  we  assume  that  there  is  just  one  processor  in  the  system. 
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Corresponding  to  the  two  types  of  instruction- sources,  we  distinguish 
between  two  types  of  subjects.  A  subject  (INS,D)  whose  INS  is  an  external 
source  will  be  called  a  user,  and  a  subject  whone  INS  is  an  internal-source  will 
be  called  an  operator. 

Operators:  Operators  are  the  dynamic  components  of  a  system.  Every 
sequential  process  in  the  system  can  be  described  as  a  sequence  of  operations, 
each  of  which  is  the  application  of  an  operator  to  a  sequence  of  zero  or  more 
operands.  An  operator  may  have  various  side  effects  on  the  system,  but  only  one 
value  which  is  called  the  outcome  of  the  operator.  The  outcome  is  a  concrete 
object  which  is  stored  in  the  domain  of  the  subject  which  invokes  the  operator. 

He  will  distinguish  between  two  types  of  operators.  First  there  is  a  fixed 
set  of  primitive  operators  whose  internal  activity  would  not  be  subject  to  the 
control  of  our  protection  mechanism.  For  example,  the  set  of 
machine- instructions  may  be  considered  the  primitive  operators  of  an  operating 
System.  Secondly,  an  operator  may  be  a  subject  (INS,D)  whose  source  of 
instruction  is  a  proce^  re  maintained  by  the  system.  Note  the  recursive  nature 
of  the  operator  concept:  A  procedure,  which  is  the  INS  component  of  some 
operator,  has  been  defined  to  be  a  source  of  instructions,  while  an  instruction 
is  a  request  to  invoke  an  operator. 

Authorization  scheme  and  policies:  Following  Jones  and  Hulf  [Vul  7*1  we 
distinguish  between  the  concept  of  "authorization-scheme"  and  that  of  "policy”. 
A  oollev  is  a  sv  'tfic  discipline  which  one  would  like  to  impose  on  a  system. 
It  will  occasionally  be  called  "authority-structure".  An  authorization  (or 
protection)  scheme  is  a  framework  which  should  be  general  enough  t:  ac  jmodate  a 
variety  of  policies,  as  efficiently  and  conveniently  as  possible.  Such  »  *( rm- 


consists  of  two  main  components:  A  "language"  which  can  be  used  for  the 
•pacification  of  policies ,  and  an  enforcement-nec hanlsa  which  guarantees  that  no 
illegal  operations  are  carried  out. 

ImZL  Activators  and  the  enforcement  mechanism 

An  activator f  is  a  oonorete  object  which  we  denote  by: 

A  e  <o  ,  p1,...,pk  i  G>  — ^  po 

Bare  1  is  the  nane  of  the  activator;  a  is  an  operator- Identifier :  pi,  for 
1*1, ...,k  is  a  condition  a&  the  1-th  operand  of  a,  to  be  called  "operand 
pattern";  £  is  a  condition  defined  on  all  operands,  and  possibly  on  other 
objects  In  the  ayaten,  (it  will  be  called  the  "global  condition”  of  A);  and  po 
la  a  condition  on  the  outcome  (result),  of  the  operator,  to  be  called  the 
"outcome  pattern"*.  (Whenever  we  do  not  wish  to  distinguish  between  operand 
patterns  and  outcome  patterns  we  will  use  the  term  "activation  pattern"  or  just 
•pattern".) 

The  existence  of  an  o-activator  A  in  the  domain  of  a  subject  S  represents 
the  authority  for  S  to  apply  the  operator  SL  to  any  objects  q1,...,qk  in  the 
domain  of  S,  provided  that  for  every  isl,...,k  the  operand  qi  matches  the 
operand-pattern  pi  of  A  (satisfies  the  condition  pi),  and  that  the  global 
condition  0  of  A  is  satisfied.  The  activator. A  also  gives  S  the  authority  to 


(*)If  the  operator  a  does  not  have  an  outcome  then  the  part  ■— >po"  will  not 
appear  in  our  notation.  Also,  the  condition  £  may  be  absent.  Thus,  an 
activator  may  be  denoted  simply  by  A  «  <o,p1,...,pk> 
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introduce  into  its  own  domain  the  outcome  of  the  operator  £,  thus  invoked, 
provided  that  this  outcome  "Batches”  the  outcome-pattern  po  of  A  (that  is, 
satisfies  the  condition  po).  To  support  this  interpretation  of  the  activators 
the  following  enforcement  mechanism  is  proposed. 

Let  us  define  an  instruction  to  be  the  construct 

A(q1,...,qk) 

where  i  is  an  o-activator  for  some  operator  o  and  qi  are  its  operands.  It  is 
also  assumed  that  a  subject  can  form  such  an  instruction  only  from  concrete 
objects  A,q1,...,qk  which  exist  in  its  own  domain.  Thus,  the  set  of 
instructions  which  are  expressible  by  a  subject  is  directly  determined  by  the 
WT7  content  of  his  domain.  Moreover,  such  an  instruction  is  carried  out  only  if  the 
operands  "match"  the  activation  patterns  as  described  above,  and  if  G  is 
satisfied.  It  is  the  responsibility  of  the  enforcement  mechanism  to  perform 
this  "pattern  matching"  and  to  guarantee  that  no  illegal  operations  are  carried 
out.  Once  an  operation  is  carried  out,  its  outcome,  if  any,  is  checked.  If  it 
matches  the  pattern  po  it  will  be  added  to  the  operating-domain;  otherwise,  the 
value  of  the  operation  is  lost,  and  an  error  procedure  may  be  invoked. 

Mote  that  an  operand  qi  may  be  of  two  types:  it  may  be  a  concrete  object, 
such  as  an  integer  number,  which  stands  for  itself;  or  it  may  be  a  ticket  that 
addresses  a  'arable  object,  which  is  the  real  operand.  Even  in  the  latter  case 
we  will  usually  refer  to  qi  as  an  operand,  relaying  on  the  context  to  determine 
whether  qi  itself  is  meant  or  the  object  addressed  by  it. 


Page  16 


Tims,  it  is  clear  that  the  content  of  the  domain  0  of  a  subject  S,  at  a 
given  naaent  in  tine,  determines  the  set  of  operations  which  can  be  carried  out 
by  S  at  this  moment.  Ve  can  say  therefore,  that  the  domain  of  £  auhi»n», 
deicrainea  its  capabilities,  or  its  authority. 

There  ia  an  instructive  analogy  between  the  role  of  the  activators  in  our 
scheme  and  the  role  of  enzvmea  as  the  control  devices  of  the  living  cell.  The 
Auction  of  every  enzyme  is  to  facilitate  a  certain  chemical  reaction.  Such  a 
reaction  takes  place  if  there  are  enough  substrates  in  the  cell  which  fit  the 
rctivation-sltes  on  the  enzyme,  in  some  analogy  to  the  function  of  our  activator 
(see  figure  2).  Although  this  analogy  between  activators  and  enzymes  should  not 
be  carried  too  far,  it  does  provide  an  interesting  viewpoint  of  the  proposed 
scheme. 

«••••••••• 

•  Fig  2  • 


Vote  the  similarity  between  the  activators  and  the 
formal-parameters-soeciflcation  (or  FPS)  of  procedures  in  programming 

languages:  Both  determine  the  legal  set  of  operands  of  an  operator.  There  is, 

% 

however,  an  important  difference  between  these  two.  Our  activator  is  an 
independent  object,  disconnected  from  the  operator  which  it  activates. 
Moreover,  while  there  is  just  one  FPS  per  operator  we  will  see  below  that  there 
may  be  several  different  o-activators  for  the  same  operator  o,  which  have 
different  strength.  The  concept  of  "strength  of  activators"  is  defined  below. 
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Let  A  be  an  activator  of  order  k  (with  k  operand-patterns) .  He  define 
MMtgaf A)  to  be  the  set  of  all  possible  (k+O-tuples  (q1,...,qk,qo)  of  objects, 
which  can  be  matched  with  the  corresponding  activation- pat terns  of  A(  and  which 
satisfy  the  condition  G  of  A. 

Let  A  and  A'  be  two  o-activators  for  a  given  operator  o.  He  will  say  that 
A'  is  weaker  than  A  (or,  equivalently,  A  is  stronger  than  A')  iff 

range( A* } £ range( A) . 

He  will  say  that  A'  is  strictly  weaker  than  A  iff 

range(A')  C  range(A), 

such  an  A*  will  also  be  called  a  reduction  of  A. 

'  ^  As  to  the  generation  snl  manipulation  £l  activators,  the  following  is 

assumed:  First,  there  is  no  way  to  change  an  existing  activator,  except  to 
erase  it.  Secondly,  new  activators  can  be  generated  only  in  the  following  two 

ways: 

a)  Hhen  a  new  operator  o  is  created,  an  o-activator  is  generated  with  it. 
It  will  be  called  the  primary  o-actlvator. 

b)  Given  an  o-activator  A*  it  maybe  possible  to  generate  a  new  activator 
A* ,  which  is  called  a  derivative  of  A»  A*  cannot  be  stronger  than  A* 
(Later  we  will  see  when  it  is  actually  possible  to  generate  such  a 
derivative.) 

The  following  properties  of  the  activators  follow  immediately  from  the  above: 

a)  The  set  of  all  o-activators,  for  a  given  operator  o,  is  partially 
ordered  with  respect  to  the  relation  "stronger* . 

b)  Every  activator  is  stronger  then  all  its  derivatives 
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o)  The  primary  o-activator  is  the  strongest  o-activator. 

Hi  Sis.  activation  patterns 

lb  be  more  concrete  about  the  activators  and  their  use  we  have  to  suggest  a 
specific  structure  for  the  activation-patterns.  The  structure  to  be  described 
below  is  designed  to  support  many  of  the  known  authority  structures  in  computer 
systems,  note  that  the  run  time  overhead  due  to  the  enforcement  mechanism  which 
is  necessary  to  support  our  scheme  depends  on  the  complexity  of  the  activation 
patterns  and  that  of  G.  In  this  paper  we  do  not  impose  any  restriction  on  this 
complexity,  because  such  restrictions  should  depend  on  the  nature  of  the  system 
to  be  protected. 

Operand-patterns :  An  operand  pattern  P,  to  be  denoted  by 

CljBjV] 

is  a  conjunction  of  three  predicates  I,R,Vt  which  are  called  components,  or 
sub-patterns  of  P.  They  are  defined  below. 

The  sub-pattern  X  (which  is  the  only  mandatory  part  of  P)  is  called  the 
identity-based  sub-pattern.  It  is  either  a  type  identifier,  "t",  which  is  meant 
to  be  satisfied  by  any  object  of  type  £;  or  it  is  the  phrase  "b:tM  which  is 
satisfied  only  by  the  particular  object  &  of  type  £,.  The  entire  pattern  P  whose 
I  component  identifies  a  type  t  will  be  called  a  t~ pattern.  The  structure  of 
the  two  other  components  of  a  t- pattern  depends  on  t.  If  a  subpatte.rn  R  or  V 
does  not  appear  in  P,  it  would  be  interpreted  as  identically  TRUE,  which  means 
that  it  does  not  impose  any  restrictions  on  the  object  matched  to  the  pattern. 
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The  sub-pattern  H,  called  the  privilege- based  subpattern,  is  applicable 
only  in  the  case  that  t  is  a  shared-type.  R  has  the  general  fora: 

R  *  r14r24,...,4rk 

where  each  ri  is  a  symbol  which  belongs  to  rights?  t) .  R  is  meant  to  be 
satisfied  by  any  ticket  of  a  t- object  which  contains  least  the  right 
ri ,  •  •  • ,rk. 

The  sub-pattern  JL,  called  the  value- based  subpattern,  is  a  predicate 
defined  on  the  facade  of  the  object  being  matched  with  it. 

An  example:  Let  doc  be  a  type  of  sbarable  objects  which  carry  documents  in  a 
military  information  system.  Let  the  facade  of  doc-objects  be  defined  by: 

facade(doc)  *  {slevel: integer,  category: text} 

where  slevel  is  an  integer  which  specifies  the  "security-level"  of  the  document, 
end  category  specifies  its  category,  such  as  "navy"  or  "army”.  These  two 
attributes  are  the  traditional  security  parameters  in  military  establishments 
[Uel693.  Let 


rights(doc)  *  (U,E) 

As  we  will  see  below,  the  symbols  "U"  and  "E"  stand  for  the  rights  to  update  and 
erase  a  document,  respectively. 
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Suppose  now  that  there  are  three  doe-opera tors:  read,  undate  and  erase r 
which  are  the  only  operators  able  to  manipulate  a  document  directly  (see  section 
3.1.1).  The  primary  activators  of  these  operators  are  as  follows: 

READ  *  <read ,  [doc]  > 

UPDATE  *  < update,  [doc;U]«  [text]  > 

ERASE  *  < erase,  [doc;E]  > 

The  activator  READ  can  be  applied  to  any  doc- ticket t  displaying  the  content  of 
the  document.  The  activator  UPDATE  can  be  applied  to  a  doc- ticket  which 
contains  the  NUM  right.  The  second  operand  of  UPDATE,  which  can  be  any 
text-object,  specifies  the  nature  of  the  desired  update.  The  activator  ERASE 
can  be  applied  to  any  doc- ticket  which  contains  the  "E"  right*  erasing  the 
content  of  the  document. 

The  right  "U*  can  properly  be  considered  an  "update-right"  due  to  the 
following  reason:  "U"  is  required  by  the  primary  update-activator*  which  means 
that  it  would  be  required  by  all  update-activators.  Thus*  the  update  operator 
can  never  be  applied  to  a  doc- ticket  which  does  not  have  the  "U"  right.  A 
similar  argument  would  show  that  "E"  is' the  "erase-right". 

As  has  already  been  explained*  the  primary  o-activator*  for  any  given 
Operator  o*  allows  for  the  most  general  use  of  o.  In  order  to  provide  for  a 
more  limited  use  of  o  one  creates  weaker  derivatives  of  the  o-activator.  For 
example*  the  activator 


CHASE '  >  <eraae*  [doc:E,U]  > 
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la  weaker  than  ERASE  because  it  can  be  applied  only  to  a  doc- ticket  which  has 
both  "0"  and  "E"  rights  in  it.  The  following  activator 

ERASE"  s  < erase ,  [d:doc;E]  > 

is  also  weaker  than  ERASE,  because  it  can  erase  only  a  specific  document  £. 
Note,  howe'er,  that  there  is  no  ordering  relation  between  ERASE*  and  ERASE". 
Neither  of  them  can  be  a  derivative  of  the  other. 

To  illustrate  the  use  of  value-based  sub-patterns  consider  a  subject  S 
whose  domain  D  cor tains  the  following  activators. 

READ*  s  <read,  [doc;;  slevel  i  2]  > 

UPDATE*  =  <update,  [doc;U;  slevel£2  &  cat egory= "navy"] ,  [text]  > 

which  are  reduced  derivatives  of  READ  and  UPDATE,  respectively.  S  has  the  power 
to  read  any  document  whose  security  level  is  smaller  than  or  equal  to  2  and 
whose  ticket  he  can  get.  S  can  also  update  "navy"  documents  whose  slevel  i  2, 
provided  that  be  has  a  ticket  with  the  "U"  right  for  such  a  document.  However, 
S  cannot  erase  any  document  because  he  does  not  have  any  erase-activators. 


The  outcome-pattern  po  of  an  activator 


A  a  <o,...>  — >  pO 

is  a  condition  on  the  outcome  of  the  operator  £,  when  invoked  by  means  of  A. 
This  means  that  only  an  outcome  which  satisfies  po  can  be  added  to  the  operating 
domain  by  using  A.  The  structure  of  the  outcome-patterns  is  identical  to  that 
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Of  the  operand-patterns .  However,  the  interpretation  of  the  R-conmonent  of  the 
pattern  is  different.  Let  po  be  the  pattern  [I;  r1&r2&. .  .&rn;  V).  The 
right- symbols  r1,...,rn  in  this  pattern  are  not  treated  as  conditions  oh  the 
rights  r(c)  contained  in  the  ticket  £  returned  as  the  outcome  of  the  operation. 
Bather,  they  serve  as  a  filter  on  r(c),  in  the  following  sense:  Any  right  in 
r(e)  which  is  not  represented  in  r1,...,rn  would  be  erased  from  the  outcoming 
ticket  £.  Thus,  the  component  Ji  ££  £2  serves  as  the  upper  limit  for  ■  the  rights 
which  might  be  returned  as  a  result  of  applying  the  activator.  This  means,  for 
example,  that  the  activator 

<o,p1  >— *  [I1;r1;V1]. 

is  weaker  than 

<ofp1>— ^  [I1;r1,r2;?1] 

Returning  to  our  document  example,  consider  an  operator  getdoc  which 
retrieves  documents  from  files.  Let  the  primary  activator  of  getdoc  be 

GET  *  <getdoc,  [file],  [text]  >  — ^  [doc; ALL] 

The  first  operand  of  getdoc  must  be  a  file  of  documents,  in  which  getdoc  is 
supposed  to  locate  a  document  identified  by  the  second  parameter,  returning  the 
tioket  for  the  document  as  its  outcome.  Note  that  the  outcome-pattern  [doc; ALL] 
would  match  any  document- ticket.  Consider  now  the  following,  weaker,  derivative 
of  GET: 

GET*  «  <getdoc,  [f1:file],  [text]  >  — ^  [doc;U;slevel=1] 
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GET*  can  get  documents  only  from  a  specific  file  XI*  moreover  It  can  produce 
only  tickets  for  documents  whose  security-level  equals  1,  and  these  tickets  can 
have  no  more  than  the  "U"  right  in  them. 

.UL  Control  over  the  generation  of  ob  jects 

As  we  saw  in  the  last  section,  one  can  control  the  use  of  individual 
existing  sharable  objects  by  the  distribution  of  their  tickets.  We  will  now 
show  how  the  generation  of  new  objects  can  be  controlled.  (Only  the  essentials 
of  such  control  are  discussed ,  leaving  some  details  unspecified) .  This  will 
serve  as  a  farther  illustration  of  activators  and  their  patterns. 

First,  we  assume  that  there  is  a  primitive  operator  gen- type  which  is  able 
to  generate  new  type-objects  (the  objects  in  the  second  level  of  the  tree  in 
X~7F  Figure  1).  Let  the  primary  activator  of  this  operator  be: 

GEN-TYPE  =  <gen- type , >  — P  [  template  ;ALJ.] 

This  activator  has  a  sequence  of  operand-patterns  not  specified  here,  which 
determine  the  type  of  arguments  which  are  required  by  gen- type.  Invocation  of 
GEN-TYPE  would  generate  a  template-object  returning  a  ticket  for  it  with  all  its 
possible  rights.  Obviously,  only  a  subject  who  has  the  GEN-TYPE  activator,  or 
some  derivative  of  it,  can  generate  new  types. 

He  now  assume  that  together  with  a  new  type-object  t,  the  following 
"Instantiation-activator"  is  generated 


<gen-t  ,p1,...,pk> 


CtjAll), 
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where  gen-t  la  an  operator  which  generates  instances  of  type  t,  and  pi , . . . ,pk 
determine  the  arguments  required  by  gen-t.  Application  of  this  activator  to  an 
appropriate  sequence  of  operands  returns  a  ticket  to  the  newly  formed  t-object, 
with  all  the  rlghts(t)  In  it.  For  example,  the  primitive 
instantiation-activator  for  the  type  doc  may  be: 

GEN-DOC  =  <gen-doe ,  content : [ text] ,  slevel : [ integer] , 

category: [text]  >  — >  [doc; ALL] 

(To  distinguish  between  the  various  operand-patterns  we  use  labels  such  as 
•con tent .  The  three  operands  of  gen- doc  determine  the  initial  state  of 
the  generated  document:  its  content,  aecuritv-level  and  category.  A  subject 
who  has  this  activator  can  generate  documents  with  arbitrary  security-level  and 
category,  and  be  gets  a  ticket  for  the  generated  object  with  all  its  possible 
rights.  However,  a  subject  who  has  the  following  derivative  of  GEN-DOC 

GEN-DOC*  a  <gen-doc , . . . .category: [text; ; value* "navy" ]>  >  [doc;E] 

can  generate  only  documents  whose  category  is  "navy",  getting  for  them  tickets 
without  the  "U"  right.  Note  that  documents  generated  by  GEN-DOC*  can  never  be 
changed,  because  there  can  be  no  tickets  with  the  "U"  right  for  them. 

As  to  the  control  over  the  distribution  of  the  instantiation-activators, 
the  following  is  assumed :  The  primary-  instantiation  activator  of  a  type  t  is 
stored  Inside  the  template-object  t  itself.  It  can  be  accessed,  and  copied  or 
moved  to  other  places  by  a  subject  who  has  an  access  to  an  appropriate  ticket  of 
the  template  object  t.  (See  section  3.8  for  inform.-. tion  about  the  transport  of 
activators  and  tickets.) 

Li  The  two  types  of  oontrol-oblecta:  their  role  and  behavior 
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Our  protection  scheme  is  based  on  two  primitive  types  of  objects, 
I  activators  and  tickets ,  which  we  call,  collectively,  "control-objects*.  The 

distribution  of  control-objects  throughout  the  system  serves  to  determine  its 
authority-state,  namely,  such  distribution  determines  who  can  do  what  in  the 
system.  The  roles  of  the  two  types  of  control-objects  is  reviewed  in  this 
section,  and  their  transport  is  discussed. 


X 

% 

I.  • 

■ 


There  is  a  symmetry  in  the  function  of  activators  and  tickets  in  our 
scheme.  A  ticket  for  object  b  which  resides  in  the  domain  D  of  a  subject  S 
represents  the  privileges  that  S  has  to  b,  in  the  sense  that  the  ticket 
determines  the  set  of  operators  which  may  be  applied  by  S  to  b.  Analogously,  an 
o-activator  which  resides  in  0  represents  the  privileges  that  S  has  to  the 
operator  o,  in  the  sense  that  it  defines  the  set  of  objects  to  which  o  can  be 
applied  by  S.  Tickets  and  activators  also  play  complementary  roles  in  our 
scheme:  neither  one  of  them  alone  is  sufficient  for  the  application  of  an 
operator  to  a  sharable-object.  For  thi^,  one  needs  both  an  activator  and  a 
ticket  (or  several  tickets)  which  fit  the  activator. 


^  The  complementarity  of  activators  and  tickets  allows  us  to  formalize  the 

semantics  of  the  right-symbols.  Let  the  symbol  rl  belong  to  rights( t)  for  a 
!  given  type  £.  We  define  the  privileges  associated  with  rl  to  be  the  set  of 

t-patterns  of  the  various  activators  in  the  system  which  require  rl .  Moreover, 

'  for  a  given  domain  D  we  define  the  local  privileges  associated  with  rl  to  be  the 

T»i 

f  '  set  of  t-patterns  la  £  which  require  £l.  Note,  for  example,  that  this  set  may 


be  empty,  rendering  £l  useless  in  the  context  of  D,  even  if  the  set  of  global 
privileges  of  rl  la  non-empty.  For  instance,  the  right  *U”  of  section  3*1  would 
be  useless  within  a  domain  which  has  no  update-activators. 
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"The  two  types  of  control-objects  exhibit  some  similar  structural  and 
behavioral  characteristics,  which  are  best  seen  by  comparing  the  following  two 
eats:  the  set  T(b)  of  all  tickets  for  a  given  object  b,  and  the  set  A(o)  of  all 
4>-actlvators .  T(b)  and  A(o)  are  partially  ordered  sets  with  respect  to  the 
relation  Stronger,  defined  for  tickets  and  activators  respectively.  Every 
ticket  in  T(b)  is  a  direct,  or  indirect,  derivative  of  the  primary  ticket  of  b, 
which  is  created  together  with  the  object  b  Itself.  Likewise,  every  activator 
la  A(o)  is  a  derivative  of  the  primary  o-activator,  which  is  created  together 
with  the  operator  o.  A  control-object,  whether  it  is  an  activator  or  a  ticket, 
la  btronger  than  all  its  derivatives. 

Control-objects  are  to  be  distributed  by  means  of  two  primitive 
"transport-operators”:  k-conv  and  k-move.  ("k"  stands  for  ”kernel”,  as  these 
operators  should  belong  to  the  kernel  of  the  system,  to  be  discussed  in  section 
3.8) .  Each  of  these  operators  when  applied  to  a  control-object  £2  generates  a 
aaw  control-object  co'  in  some  other  place  in  the  system,  such  a  co'  cannot  be 
stronger  than  co.  The  difference  between  the  two  transport  operators  is  that 
k-copy  does  not  affect  the  original  control -object  while  k-move  erases  it. 
Thus,  k-move,  in  effect,  moves  a  control-object  from  one  place  to  another, 
possibly  reducing  it  in  the  process. 

In  order  to  get  a  degree  of  control  over  the  transportability  of  individual 
control-objects,  the  following  facility  is  introduced.  The  facade  of  a 
control-object  of  either  type,  consists  of  two  boolean  components,  "copy”  and 
"move" ,  to  be  called  the  "intrinsic  rights”  of  the  object.  The  operator  k-copy 
non  be  applied  to  a  control-object  co  only  if  "it -has  the  copy  right”,  namely, 
if  the  "copy"  component  of  co  is  TRUE.  Likewise,  k-move  can  be  applied  only  to 
•  control  object  which  has  the  "move"  right.  Thus,  a  control-object  with 


neither  intrinsic-rights  is  untransportable.  Of  course,  the  control-object  co* 
generated  from  co  by  one  of  these  operators  cannot  have  more  intrinsic-rights 
than  co,  but  it  can  have  less. 

It  is  obviously  vital  to  have  some  control  over  the  use  of  the 
transport-operators.  Such  a  control  can  be  achieved  by  the  distribution  of 
their  activators.  These  activators  will  be  discussed  in  section  3*8. 

Ui  The  structure  of  domains,  and  their  dynamic  behavior 

As  has  already  been  explained,  the  content  of  a  domain  D  at  a  given  moment 
in  time,  T,  determines  the  set  of  operations  which  can  be  carried  out  at  time  T 
by  the  subject  S  associated  with  D.  But  what  can  we  say  about  the  future 
capabilities  of  the  subject  S?  To  answer  this  question  one  must  be  able  to 
predict  the  future  content  of  D.  This  in  turn,  requires  an  understanding  of  the 
dynamic  behavior  of  domains. 

Uul  External  and  internal  changes  of  domains.  Ve  will  distinguish  between 
two  types  of  domain  change,  to  be  called  "external  changes"  and  "internal 
changes".  An  external  change  of  a  domain  D  associated  with  subject  S  is  a 
change  caused  by  an  operation  invoked  by  another  subject.  S' .  In  particular,  it 
is  such  a  subject  S'  which  created  0  in  the  first  place.  In  order  to  predict 
the  dynamic  behavior  of  a  given  domain  D  under  external  changes  one  must  be  able 
to  tell  which  subjects  have  the  capability  of  changing  D,  and  what  are  they  up 
to. 

An  internal  change  of  a  domain  D  is  one  which  is  caused  by  an  operation 
Invoked  by  its  own  subject  S,  as  follows:  Let 
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A  •  <...> 


po 


be  an  activator  in  0,  and  let  A(q1,...,qk)  be  an  operation  invoked  by  S. 
lhe  outcome  of  this  operation,  if  any,  is  added  to  0.  This  outcome  la  a 
concrete  object  which  satisfies  do.  (Note  that  depending  on  po,  the  outcome 
idiich  is  added  to  the  domain  may  be  a  primitive  object  such  as  integer,  a  ticket 
for  a  sharable  object,  or  even  an  activator).  Thus,  the  nature  of  the  possible 
Internal  changes  of  a  domain  D  are  determined  explicitly  by  the  content  of  D 
Itself. 


*  low,  it  seems  reasonable  to  assume  that  in  a  well-designed  system  there 
asuld  usually  be  only  a  small  number  of  subjects  S'  which  are  able  to  change  an 
existing  domain  D.  Moreover,  even  these  subjects  are  not  likely  to  exercise 
their  ability  to  change  D  very  often,  so  that  an  external  change  of  a  domain  is 
likely  to  be  a  relatively  rare  event.  Therefore,  we  continue  our  discussion  of 
the  dynamic  behavior  of  domains  taking  only  internal  domain-changes  into 
account. 


3-6-2  The  structure  of  domains;  Until  now,  domains  have  been  presented  as 
monolithic  structures.  We  will  now  distinguish  between  two  parts  of  a  domain, 
to  be  called  "permanent"  and  "transient"  parts.  The  permanent- part  of  the 
domain  of  a  subject  S  is  created  .with  the  subject,  and  is  attached  to  it 
throughtout  its  lifetime.  We  will  sometimes  refer  to  this  part  simply  as  "the 
domain"  of  the  subject.  The  transient-part  of  the  domain,  to  be  also  referred 
to  as  the  "workspace"  of  the  subject,  exists  only  for  the  duration  of  a  single 
"activity-period"  of  the  subject.  In  the  case  of  a  user  an  activity-period  is  a 
mingle  "session"  of  user-system  interaction.  An  empty  workspace  is  attached  to 
the  domain  of  the  user  at  the  beginning  of  a  session,  only  to  disappear  when  the 
mansion  terminates.  An  activity-period  of  an  operator  is  the  period  between  its 


T 
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Invocation  and  Its  return.  When  an  operator  is  Invoked,  a  new  workspace,  which 
contains  all  the  operands,  is  attached  to  its  domain,  to  he  deleted  when  the 
operator  returns  control. 

He  now  introduce  the  convention  that  unless  specified  otherwise,  an 
internal-change  of  a  domain  effects  its  transient  part  only.  This  Beans  that 
the  outcome  of  an  operation  is  usually  stored,  in  the  workspace  of  the  subject, 
leaving  the  permanent  part  of  the  domain  invariant  of  the  activity  of  its  own 
subject.  An  example  will  clarify  all  that. 

1.6.3  An  example:  Consider  a  subject  S  whose  domain,  or  rather,  the 
permanent-part  of  its  domain,  is  given  in  Figure  3.  This  domain  contains  two 
file- tickets,  for  files  fl  and  f2,  which  are  assumed  to  contain  documents.  The 
domain  also  contains  five  activators:  The  activators  GET*  and  GET*  are 
reductions  of  the  activator  GET  (cf.  section  3.3.1).  Each  activator  gets  a 
doe-ticket  Identified  by  its  second  operand,  from  the  file  identified  by  its 
first  operand.  GET*  can  be  applied  only  to  a  ticket  of  one  file,  fl.  Namely, 
(XT'  can  be  used  to  generate  tickets,  with  the  ”0*  right,  for  docwents  stored 
in  fl.  He  will  denote  the  set  of  all  such  tickets  by  Fl.  The  activator  GET*, 
which  can  be  applied  to  the  ticket  c2  of  the  file  f2,  can  generate  a  set,  F2,  of 
tickets  of  documents  stored  in  f2  whose  slevelsi.  These  tickets  would  have  only 
the  *E"  right  in  them. 

MIMMIII 
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The  Activators  READ',  UPDATE*  and  ERASE*  already  dlacusaed  in  section  3.3, 
can  be  applied  to  the  doc- tickets  generated  try  GET*  and  GET”.  READ*  can  be 
.applied  to  any  docaaant  whose  slevel<2.  Mete,  therefore,  that  aoae  of  the 
documents  whose  tickets  aay  be  generated  by  GET*  cannot  be  read  by  S.  UPDATE* 
cob  be  used  to  update  aay  "navy*  document,  provided  that  Its  ticket  has  the  "U" 
right.  This  aeons  that  none  of  the  documents  from  12  can  be  updated  by  S,  and 
only  some  of  the  docunents  on  fl,  the  "navy"  documents,  can  be  updated, 
finally*  using  ERASE,  S  can  erase  all  the  docunents  he  gets  from  fl ,  but  none 
frets  12.  (Note  that  our  subject  cannot  generate  new  docunents,  because  he  does 
cot.  have  a  gen-doc  activator) . 

Rote  that  all  the  doc- tickets  generated  by  our  subject  would  be  Inserted 
into  its  "workspace”,  which  la  the  transient-part  of  the  domain  that  disapperas 
at  the  end  of  the  session.  That  Is  to  say,  the  subject  S  cannot  have  any 
d oo- tickets  for  extended  periods  of  tine.  This  property  of  our  scheme  is  very 
important  as  it  reduces  the  need  for  revocation. 

|  potmen  t:  The  domain  In  Figure  3  is  incomplete  in  the  sense  that  it  contains 
no  activators  for  basic  operations  such  as  integer-addition  or  manipulations  of 
test  variables.  Such  activators  are  necessary  because,  by  our  definitions,  mi 
operation  can  be  carried  out  by  subject  without  having  the  proper  activator  in 
his  domain.  However,  follwoing  (Min76]„  we  assume  that  all  control-objects 
Which  are  necessary  to  authorize  the  use  of  operators  and  objects  which  we  do 
not  wish  to  restrict  are  included,  by  default,  in  all  domains. 


1.T;  The  global  condition  of  activators 
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Ve  define  the  condition  G  of  activators  by  the  following  two  properties: 

a)  G  is  a  conjunction  of  predicates:  gUg2l...4gk  _ 

b)  The  reduction  of  a  global  condition  can  be  performed  by  adding  a  conjunct 
to  it,  not  by  a  change  of  existing  predicates. 

At  this  point,  no  restrictions  are  imposed  on  the  individual  predicates  gi.  In 
particular,  gi  can  be  defined  on  all  the  operands  of  the  activators,  as  well  as 
on  other  objects  in  the  system  which  are  not  otherwise  involved  in  the 
operation.  Moreover,  we  will  allow  gi  to  have  side  effects.  Here  are  some 
applications  of  the  global-condition. 

3.7  ..T:  Correlation  between  operands;  The  operand  pattern,  pi,  has  been  defined 
to  be  a  condition  on  the  i-th  operand.  Since  G  can  be  defined  on  all  operands, 
it  can  correlate  them.  For  example,  let  copvd  be  an  operator  which  copies  the 
content  of  one  document  (doc-object)  into  another.  Consider  the  following 
copyd-actlvator 

<oopyd,d1:[doc],d2:[doc;u]  f  dl. category* d2. category  A 

dl.slevel  i  dZ.slevel  > 

The  only  restriction  imposed  by  this  activator  on  the  individual  operands  is 
that  d2  must  have  the  *U*  right,  (without  which  the  update  of  d2  would  not  be 
possible).  However,  the  G  part  of  the  above  activator  requires  the  two  operands 
to  be  of  the  same  category,  and  that  the  second  operand  should  not  have  a  lower 
security  level  then  the  first.  (This  is  a  very  common  type  of  restriction  in 
military  information  systems.) 

3.7.2;  Conditions  on  global  status-variables ;  Suppose,  for  example,  that  there 
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is  a  global  variable  T  in  the  systea  which  represents  the  real-time.  The 
following  activator 


<...|  timt2  > 

oaa  be  used  only  In  the  tlae  period  (tl ,t2)  because  its  G  part  would  return 
FALSE  at  any  other  tlae.  In  a  similar  way  one  can  construct  activators  which 
are  conditioned  on  other  global  variables  in  the  systea. 


ImIaI  self  destructive  activators;  Consider  a  predicate  count-down  of  the  fora 
BEGIN  OWN  N; 

■  <-  1-1; 

IF  II  0  RETORN  FALSE; 

no 

If  this  predicate  is  used  as  a  component  of  the  £  part  of  an  activator  A*  it 
would  llait  the  nraber  of  tines  that  A  can  be  used.  If,  for  example,  the  own 
variable  N  of  such  a  count-down  predicate  is  initialized  to  2  when  the  activator 
la  created,  then  after  two  applications  of  A  it  will  return  false,  preventing 
further  use  of  A. 

ImULL  Hfilflgflfctaa  at  activatorsO;  One  of  the  classical  problems  in 
capability- based  protection  is  how  to  revoke  a  privilege  already  granted. 


(*)I  am  indebted  to  Dorothy  Denning  for  suggesting  this  important  application  of 
the  global  condition  of  activators. 


r 


Pt|«  33 


Revocation  of  tickets  has  been  studied  extensively  by  Redell  [Red74],  Cohen 
[Coh75]  and  others.  Here  we  will  see  bow  activators  can  be  revoked. 

Consider  a  subject  SI  who  has  an  activator 

11  ■  <...|  g  > 

in  his  domain  D1.  Let  al  be  a  boolean  variable  local  to  01.  Suppose  that  SI 
generates  a  derivative  12  of  11 

12  t  <...|  g  &  al  > 

storing  it  in  the  domain  02  of  subject  S2  (see  figure  4).  It  is  quite  obvious 
that  12  can  be  used  only  as  long  as  the  boolean  variable  al  is  TRUE.  Thus, 
although  12  belongs  physically  to  S2,  it  is  still  controlled  by  SI  which  can 

prevent  the  activation  of  12  simply  by  turning  off  the  variable  al.  Moreover, 

every  derivative  of  12  would  be  controlled  by  SI  in  the  same  way  because  it  is 
impossible  to  remove  a  conjunct  from  G.  Moreover,  one  can  add  additional 
controls  in  a  similar  way.  For  example,  let  a2  be  a  boolean  variable  in  02,  and 
suppose  that  S2  generates  a  dervative 

13  «  <...|  g  &  al  1  a2  > 

of  12,  storing  it  in  the  domain  03  of  S3  (see  figure  4).  Now,  SI  can  deactivate 

and  reactivate  both  12  and  13  by  turning  al  off  and  on,  while  S2  can  control  13 

in  a  similar  way  by  means  of  its  own  variable  a2. 


•  Fig  4  • 
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lot*  that  in  a  similar  way  one  can  construct  a  variety  of  revocation  patterns. 
In  particular,  the  variables  £l  and  a2.  above  nay  be  stored  inside  some  shared 
object  whose  tickets  are  distributed  in  a  certain  way. 

Monitoring  the  use  s£.  activators:  Using  the  ability  of  G  to  produce  side 
effects,  one  can  monitor  the  use  of  activators,  as  follows.  Suppose  that  a 
subject  SI  has  the  activator 


11  •  <...|  g  > 

in  his  domain  01.  Let 

*2  a  <...|  g  &  a  > 

be  a  derivative  of  A1  where  a  is  a  predicate  which  always  returns  TRUE,  and 
which  is  programmed  to  write  a  record  into  a  file  accessible  to  SI,  reporting 
about  each  invocation  in  which  it  participates.  Thus,  SI  would  have  an 
audit  trail  of  all  activations  of  12  and  of  any  derivative  of  it,  because  a 
cannot  be  removed  from  an  activator.  The  users  of  12,  or  of  its  derivatives, 
say  not  be  aware  of  such  audit  trail  being  formed,  and  they  certainly  cannot  do 
anything  about  it,  because  no  part  of  G  can  be  removed  from  an  activator. 

3.8:  On  the  kernel  of  the  protection  mechanism  f )  * 


This  section  can  be  skipped  on  first  reading. 
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The  purpose  of  this  section  Is  to  clarify  and  support  sons  of  the 
assumptions  made  in  previous  sections.  In  particular,  it  has  been  assumed  that 
for  every  type  t  there  is  a  set  of  privileged  operators  with  respect  to  t,  which 
have  the  exclusive  ability  to  modify  and  observe  t-objects  directly.  Here  we 
will  show  how  this  exclusiveness  can  be  imposed  by  means  of  the  basic  protection 
mechanism.  This  discussion  will  bring  us  down  to  the  foundations  of  the 
protection  mechanism,  which  is  frequently  called  its  kernel .  However,  only  some 
aspects  of  such  a  kernel  will  be  discussed  here.  Its  complete  study  is  beyond 
the  scope  of  this  paper  because  the  kernel  is  likely  to  be  strongly  dependent  on 
its  context.  For  example,  the  kernel  would  surely  be  very  different  in  the  case 
of  operating  systems,  databases,  and  programming  languages.  Therefore,  the 
following  discussion  should  not  be  viewed  as  a  proposal  for  a  specifio 
implementation. 

3.8.1;  Segments  and  Their  Operators:  In  an  attempt  to  find  a  uniform 
implementation  for  all  types  of  sharable  objects,  we  first  define  a  primitive 
type  called  segment  which  is  to  serve  as  a  host  for  sharable  objects  of  all 
types. 

k  segment  is  essentially  a  chunk  of  storage  divided  into  a  sequence  of 
slots  each  of  which  can  host  one  concrete  object  of  a  given  primitive  type.  For 
example,  there  may  be  integer-slots,  text-slots,  ticket-slots  and 
activator-slots .  The  various  slots  in  a  segment  will  be  addressed  by  their 
relative  position  with  respect  its  origin.  This  division  of  a  segment  into 
slats  will  be  called  the  structure  of  the  segment.  A  segment  is  allocated,  to 
host  an  abject  of  a  given  type  t,  by  the  gen-t  operator  (defined  in  Section 
3  .*■)  -  The  structure  of  this  segment  is  determined  by  t,  and  is  fixed  for  the 
life-time  of  the  object. 


He  will  treat  the  set  of  all  segnents  as  a  type.  It  Is  a  special  kind  of 
type  as  It  includes  (*)  all  other  types  of  sharable  objects,  since,  by  our 
definition,  an  object  of  any  type  is  also  a  segment.  As  any  other  type  of 
Sharable  objects,  the  type  "segment"  has  its  own  rights,  which,  following  Hydra, 
will  be  called  "kernel  rights".  Ve  assume  that 

rights( segments)  =  {k-read,k-write) . 

k  ticket  (b:t;  r)  of  a  sharable  object  b  can  be  viewed  also  as  a  ticket  for  the 
segment  which  hosts  an  object  b,  provided  that  we  generalize  the  r-coaponent  of 
a  t- ticket  as  follows: 

re  ri£hts(  t)^rights(  segment) . 

that  is  to  say,  the  kernel-rights  are  common  to  all  types,  and  may  appear  in  any 
ticket. 

Ve  now  introduce  two  operators  which  operate  on  segments:  the  already 
mentioned  transport-operators,  k-conv  and  k-move.  The  primary  activator  of 
k-copy  is: 

K-COPT  =  <k-copy, si: [ segment ;k-read], loci: [integer], 

s2: ( segment ;k-write],loo2:[ integer ] ,  reduction: [text]  > 

The  operator  k-copy  copies  a  concrete  object  from  slot  loci  of  segment  gl  into 
slot  loo?  of  aZ.  The  fifth  parameter,  reduction,  specifies  the  reduction  to  be 

(•)The  concept  of  "type- inclusion"  could  have  been  introduced  formally  in 
aeotion  3.1.1.  He  avoided  this  for  the  sake  of  simplicity,  and  we  are  using 
type- Inclusion, in  an  ad-hock  manner,  only  in  this  case. 
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applied  to  the  copied  object,  if  it  happens  to  be  a  ticket  or  an  activator. 
Namely,  it  specifies  in  what  way  the  new  object  is  weaker  than  the  original  (The 
syntax  of  the  reduction  specification  will  not  be  discussed  here).  The 
conditions  for  the  copy  operation  to  be  carried  out,  are  of  two  types:  explicit 
and  implicit.  The  conditions  which  are  explicit  in  the  activator  are  that  the 
ticket  for  _al  oust  have  the  "k-read"  right,  and  the  ticket  for  _a2.  must  have  the 
"k-write"  right.  In  addition  to  these  explicit  conditions  we  assume  that  the 
following  restrictions  are  built  into  the  operator  itself. 

•  1)  The  concrete-object  in  slot  loci  of  si  must  fit  the  type  of  slot  of 

s2.  This  simply  means  that  the  k-conv  operator  does  not  violate  type 
specification  of  the  structure  of  segments.  Thus,  only  a  ticket  can  be 
stored  in  a  ticket-slot,  only  an  activator  can  be  stored  in  an 
activator- slot,  etc.  Moreover,  a  ticket-slot  may  be  earmarked  for  ticket 
of  a  certain  type  of  objects  only  and  there  may  be  a  limit  imposed  on  the 
rights  which  may  be  contained  in  the  slot.  All  such  specifications  must  be 
honored  by  k-copy. 

2)  If  the  content  of  the  loci -slot  of  si  is  a  ticket  or  an  activator,  it  must 
have  the  intrinsic-right  "copy*. 

The  second  transport-operator,  k-move.  has  a  similar  activator,  K-MOVE.  The 
only  differences  between  these  two  operators  are: 

a)  k-move  erases  the  content  of  slot  loci  of  si. 

b)  In  the  equivalent  of  restriction  (2)  above,  the  intrinsic-right  "move" 
(rather  than  "copy")  is  required. 

Mote  that  because  of  (1)  above,  a  slot  behaves  like  a  variable  in  a  typed 
language,  namely,  it  has  a  specified  range  of  objects  which  may  be  stored  in  it. 
A  particularly  important  case  is  that  of  a  "ticket-variable”  which  can  contain 
tickets  only  for  a  given  type  of  objects,  and  with  a  specified  maximal  .act  &C 


rights.  Such  a  facility,  which  is  similar  to  the  ticket  variables  introduced  by 
Jones  and  Liskov  in  [Jon76],  can  contribute  greatly  to  proving  correctness  of 
policies. 

is  we  will  see  next,  the  activators  K-COPY  and  K-MOVE  are  too  powerful  to 
be  contained  in  any  domain.  He  will  have  to  use  restricted  derivatives  of  them. 

On  the  Implementation  of  Privileged-Operators; 

For  a  given  type  t  consider  the  following  derivative  of  K-COPY: 

HEAD-t  s  <k-copy,s1:[t;k-read],loc1: [integer], 

s2:[myself] ,loc2:[ Integer] ,  reduction :[ text] > 

This  is  a  reduction  of  K-COPY  in  two  ways.  First,  the  si  pattern  can  be  matched 
only  to  tickets  of  t- objects  (which  is  a  smaller  set  than  all  segments,  which 
are  allowed  by  the  pattern  si  in  k-copy) .  Secondly,  the  phrase  "myself" ,  in  the 
s2  pattern,  is  a  context  dependent  pattern  which  matches  only  the 
operating-domain .  This  allows  a  subject  which  has  this  activator  in  its  domain, 
together  with  a  t- ticket: 

o  «  (b:t;  k-read,...), 

to  oopy  Information  from  object  b  addressed  by  c,  into  its  own  domain.  Or,  in 
other  words,  READ-t  allows  reading  of  t-ob.lects.  In  a  similar  way,  the 
activator 

VRITE-t  s  <k-oopy, si: (myself],..., s2:Ct;k-write],...> 


allows  one  to  copy  Information  from  the  operating  domain  into  t-objects,  that 
la,  to  write  into  t-oblects.  One  can  also  construct  a  pair  of  similar 
derivatives  of  K-MOVE,  which  move  data  into,  and  from  t-objects. 
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We  thus  have  four  activators  for  a  given  type  £.  which  can  be  used  for 
reading  from,  and  writing  into  t-objects.  Assuming  that  the  primary  activators 
of  k-copy  and  k-move  are  not  therselves  available,  only  a  subject  which  has  in 
its  domain  one  of  these  four  activators  is  able  to  manipulate  or  observe 
directly  t-objects.  Thus,  gn  operator  la  privileged  with  respect  to  t  if  and 
only  if  it  has  at  least  one  of  the  above  four  activators  in  its  own  domain: 
Note  that  an  operator  can  be  privileged  with  respect  to  a  number.  sL  different 
types.  This  is  not  possible  under  the  implementation  of  "abstract-types"  in 
CLU,  for  example. 


JLl  mCPSSlQH 

The  purpose  of  this  section  is  to  evaluate  the  proposed  operation-control 
(OC)  scheme  along  a  number  of  dimensions,  such  as  conceptual  adequacy  and 
simplicitly,  efficiency,  and  expressive  power.  To  keep  the  discussion  in 
perspective  we  will  compare  our  scheme  with  the  capability-based  access-control 
(AC)  scheme,  specifically  the  Hydra  [JON73,  WUL74,  COH75]  version  of  it.  Such 
comparison  is  appropriate  because,  as  we  will  see  next,  the  OC  scheme  can  be 
viewed  as  a  natural  extension  of  the  capability-based  version  of  the  AC  scheme. 

4.1:  Conceptual  simplicity 

In  comparing  our  scheme  to  the  access-control  one  it  may  seem  that  we  are 
sacrificing  a  great  deal  of  conceptual  parsimony  by  adding  another  type  of 
control-object.  This,  however,  is  not  the  case.  We  will  show  next  that  the 
proposed  scheme  can  be  viewed  as  a  natural  extension  of  the  AC-scheme.  which 


results  from  the  removal  of  an  unwarranted  restriction  in  it 


Vote  that  the  enforcement  mechanism  which  Is  necessary  to  support  the  OC 


scheme  Is  essentially  Identical  to  that  of  the  AC  scheme.  Under  the  AC  scheme, 
an  operation  o(q1,...qn)  is  considered  legal  if  the  tickets  of  the  operands 
ql, . . . ,qn  satisfy  the  requirements  Imposed  by  the  formal- parameter  specification 
(ITS)  part  of  the  operator  o  (this  part  is  ow.xed  "template”  in  Hydra).  Thus, 
the  FPS  of  an  operator  is  functionally  equivalent  to  our  primary-activator . 
Moreover,  having  the  right  to  call  an  operator  o,  under  the  AC  scheme,  is 
equivalent  to  having  the  primary  o-activator,  under  the  OC  scheme.  Thus,  the  OC 
scheme  can  be  viewed  essentially  as  a  AC  scheme  with  the  additional  degree  £JC 
freedom  which  allows  the  formation  of  a  whole  set  of  o-activators  of  different 
strength.  These  activators  represent  varying  degrees  of  authority  with  respect 
to  the  operator  £,  Just  as  the  set  of  tickets  of  a  given  object  b  represent 
varying  degrees  of  authority  with  respect  to  &.  This  symmetry  in  the  treatment 
of  objects  and  operators,  which  does  not  exist  under  the  AC  scheme,  is  important 
because  it  reflects  a  common  feature  of  authority-structures.  The  capabilities 
of  an  actor  (subject)  in  computer  systems,  as  well  as  in  the  real  world,  is 
frequently  due  to  the  type  of  operations  which  he  can  perform,  not  only  to  the 
privileges  that  he  has  with  respect  to  specific  objects.  Thus,  our  scheme  is 
conceptually  cleaner  and  more  complete  than  the  AC  scheme. 

*.2:  Expressive  power 

He  will  say  that  a  policy  is  expressible  in  a  given  scheme  if  it  can  be 
specified  and  enforced  by  means  of  the  formal  devices  provided  by  the  scheme. 
(Note  that  expressibility,  so  defined,  is  a  stronger  concept  than 
lmplementability.  Indeed,  any  policy  can  be  implemented  on  any  kind  of  system. 
Simply  by  programming  it  into  an  Interpreter  which  carries  out  every  operation 
on  the  system.)  The  difference  in  expressive  power  between  the  AC  and  the  OC 


schemes  is  primarily  along  two  dimensions:  value-dependency  and  the  ability  la 
han<M»  interactions.  It  is  not  that  value  dependent  policies  and  policies  with 
respect  to  interactions  cannot  be  expressed  in  the  AC  scheme  (although  this  is 
true  for  some  such  policies).  The  main  problem  is  that  the  implementation  of 
such  policies  tends  to  be  cumbersome  and  inefficient  to  the  point  of  being 
impractical. 

4.3.1.  Value-Dependent  policies:  We  define  a  "value-dependent  policy"  to  be 
one  under  which  the  legality  of  an  operation  depends  on  the  value  (or  state)  of 
the  operands.  In  particular,  we  will  be  interested  in  the  case  where  the 
value-dependency  itself  depends  on  the  subject  which  invokes  the  operation. 
Such  policies  can  be  represented  in  our  scheme  by  the  distribution  of  activators 
with  appropriate  value-based  patterns.  On  the  other  hand  ,  the  only  way  to 
represent  such  a  policy  under  the  AC  scheme,  is  by  a  suitable  value-dependent 
distribution  of  tickets.  That  is  to  say,  the  placement  of  tickets  depends  on 
the  values  of  the  objects  addressed  by  them.  As  we  will  demonstrate  later  by  an 
example,  such  a  representation  may  be  so  costly  and  error-prone  that  it  becoms 
completely  impractical. 

4.2.2  Handling  of  interactions:  The  concept  of  "interaction",  mentioned  in 
section  2,  is  defined,  more  rigorously  as  follows: 

For  a  given  subject  S,  an  interaction  is  an  n-ary  operator,  for  n>1,  which 
cannot  be  expressed  by  S  as  a  sequence  of  legal  unary  operations  on  its 
individual  operands. 

Mote  that  by  this  definition  an  operator  which  is  an  interaction  for  one  subject 
may  not  be  an  interaction  for  another.  Consider,  for  example,  a  procedure 
anpolnt(e.l)  which  appoints  employee  £  to  Job  j  in  a  corporate  information 
system.  Suppose  that  this  appointment  is  actually  done  by  planting  a  pointer  to 


J,  In  the  record  which  represents  £.,  and  vice  versa.  Suppose  also  that  such 
tinkering  with  pointers  is  not  allowed  outside  of  the  procedure  appoint,  for 
obvious  reasons.  Thus,  for  any  subject  other  than  the  procedure  appoint  itself, 
the  operator  appoint(e.l)  is  an  interaction  because  there  is  no  way  to  decoapose 
it  into  a  sequence  of  (more  primitive)  operations  on  £  and  ±  separately. 

How,  consider  the  following  policy  with  respect  to  the  interaction  appoint. 
Let  El  and  E2  be  two  sets  of  employees  and  let  J1,  J2  be  sets  of  jobs.  Let  S  be 
a  subject  who  is  to  be  allowed  to  appoint  employees  in  El  to  jobs  in  J1  and 
those  in  E2  to  jobs  in  J2,  but  is  not  allowed  to  appoint  employees  in  El  to  jobs 
in  J2,  etc. 

Under  the  0C- scheme,  let  pel,  pe2,  pjl,  pj2  be  patterns  which  match  members 
of  the  sets  El,  E2,  J1,  J2  respectively.  The  desired  policy  is  realized  by 
giving  S  the  activators  <appoint,  pel,  pjl  >,  and  <appoint,  pe2,  pj2  >. 

To  see  the  difficulty  under  the  AC-scheme  we  now  consider  several  attempts 
to  represent  this  policy.  First,  suppose  that  the  operator  appoint  requires  the 
right  rl  from  its  first  argument  and  r2  from  the  second.  Now,  S  can  be  given  a 
ticket  with  rl  for  every  member  of  E1,E2;  and  a  ticket  with  r2  for  every  member 
of  J1  and  J2.  The  problem  is  that  this  would  allow  S  to  make  cross 
appointments,  of  members  of  El  to  jobs  in  J2,  etc. 

The  desired  policy  can  be  Implemented  in  a  system  such  as  Hydra,  as 
follows:  One  may  maintain  a  table  inside  the  operator  appoint,  which  identifies 
the  set  of  triples  (S,  :,j)  such  that  S  is  allowed  to  appoint  £  to  job  Th® 
operator  appoint  may  be  programmed  to  obey  such  specif lcatidns.  However  this  is 
not  a  representation  in  terms  of  the  AC-scheme,  and,  it  is  quite  contrary  to  its 
underlying  philosophy  of  the  capability-based  approach  to  authorization. 
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A  correct  but  unnatural  and  very  Inefficient  representation  of  our  policy 
in  terns  of  the  AC- scheme  is  the  following:  For  every  "appo in table"  pair  (e,  j) 
we  create  an  object  jlI  which  represents  the  pair.  The  operator  appoint  can  be 
considered  as  a  unary  operator  on  such  pair-objects.  The  authority  of  our 
subject  can  be  defined  by  giving  him  a  ticket  for  every  pair-object  £±  which  S 
is  allowed  to  appoint.  Such  representation  of  authority  apart  of  being  highly 
artificial  and  inconvenient,  nay  be  extremely  inefficient.  For  example,  if  the 
cardinality  of  each  of  the  sets  E1,E2,J1,J2  is  N,  then  S  will  have  to  maintain 
211**2  tickets,  as  opposed  to  two  activators  which  are  necessary  under  our 
scheme.  Moreover, if  the  membership  of  an  employee  in  one  of  the  sets  El,  E2, 
is  determined  by  the  value  of  then  the  maintenance  of  the  authority-structure 
1s  very  difficult.  Whenever  £  stops  to  be  a  member  of  El,  say,  one  has  to 
revoke  all  existing  tickets  for  appo  in  table  pairs  e-) . 

A jJLl  Efficiency 

The  efficiency  of  a  protection  scheme  should  be  measured  along  two 
dimensions:  efficiency  of  the  representation  of  policies,  and  the  efficiency 
enforcement.  To  explain  what  we  mean  by  efficiency  of  representation  we  now 
introduce  a  number  of  concepts: 

He  will  use  the  term  "control-material"  for  the  overall  distribution  ja£ 
control  QbiCCta  throughout  &  system.  For  a  given  policy  P,  we  will  be 
interested  in  the  following  properties  of  the  control-material  which  is 
necessary  for  the  representation  of  P. 

a)  The  volume  of  the  control  material,  which  is  the  number  of  control 
objects  in  it. 

b)  The  complexity  of  the  distribution  of  the  control  material.  We  will  say 
that  the  distribution  of  the  control  material  is  more  complex,  if  there 


arc  core  rigorous  requirements  es  to  the  placement  of  the  various 
oontrol  objects. 

e)  The  yolatilitv  of  the  control  material.  Gy  the  term  "volatility”  we 
■can*  loosely  speaking,  the  amount  of  change  in  the  control  material 
which  Is  necessary  in  order  to  maintain  a  given  policy  during  normal 
operation  of  the  system,  or  to  support  incremental  changes  in  the  policy 
itself.  (  The  term  "stability”  will  also  be  used,  as  the  opposite  of 
■volatility”). 

These  aspects  of  a  protection  scheme,  and  their  relevance  to  the  efficiency  of 
the  representation  of  policies,  are  discussed  In  the  next  two  sections. 
Efficiency  of  enforcement  is  discussed  in  section  4.3.3* 

4.3. 1  The  volume  and  the  complexity the  control-material i  In  this  section 
we  will  argue  that 

tho  volume  of  the  control-material  which  is  necessary  for  the 
implementation  of  a  given  policy  under  the  OC  scheme  tends  to  be 
smaller,  and  less  complexly  distributed  than  under  the  AC-scheme. 

An  important  reason  for  this  tendency  Is  that  activators  can  have  various 
derrces  of  generality  tor,  specificity) .  which  can  be  adapted  to  the  nature  of 
the  policy  at  hand.  For  example,  the  activator  <read,  [doc]  >  can  be  used  to 
read  any  document,  while  the  activator  <read,[d:doc]  >  can  be  used  only  to  read 
the  specific  document  d.  Tickets  on  the  other  hand  have  fixed  degree  of 
specificity:  every  ticket  represents  privileges  with  respect  to  one  specific 

object.  Thus  one  may  need  many  tickets  to  represent  a  capability  which,  under 
the  OC  scheme,  can  be  represented  by  a  single  activator.  We  will  now 
demonstrate  this  tendency  by  an  example,  which  Is  a  generalisation  of  an  example 
used  by  Jones  and  Wulf  in  [Jon?5]. 


An  Example;  Let  memo  be  a  type  of  object  which  carries  memoranda.  Suppose 
that  in  addition  to  the  text  itself,  which  can  be  retrieved  by  the  operator 
read,  every  memo-object  has  a  set  of  attributes 

X  s  (x1,...,xn) 

associated  with  it,  where  all  xi  are  boolean  variables.  He  will  say  that  a  memo 
m  "satisfies  a  certain  attribute  xi”  if  xi(m)  =  TRUE  (*).  Suppose  also  that  for 
every  subject  S  there  is  a  set  Y(S)  =  (y1,...,yk)£X  of  memo-attributes  whioh 
represent  his  privileges  with  respect  to  memoranda,  as  follows:  £  should  jus. 

allowed  to  read  all  memos,  and  only  such,  -which  satisfy  all  vl  In  YtSK 

An  QC-repreaentation  of  this  policy  is  the  following. 

Let 

facade(memo)  s  (x1,...,xn) 

^  and  let  the  primary  read-activator  be 

READ  *  <read,[memo]> 

Suppose  that  a  subject  S  is  given  only  the  following  reduction  of  READ. 

READ1  s  < read, [memo; ;  yl  &,...,&  yk]> 

Suppose  also  that  the  set  of  tickets  { (m:memo) } ,  one  for  each  memo-object  in  the 
system,  is  stored  on  a  file  dir  from  which  all  subjects  can  copy  tickets.  It  ie 
obvious  that  the  desired  policy  is  satisfied  under  these  conditions. 

The  salient  feature  of  this  implementation  is  that  the  various  subjects 
have  effectively  different  "power*  with  respect  to  memo-objects,  due  to  the 
different  read-activators  in  their  domains.  That  is  why  they  can  safely  share 


(•)A  possible  interpretation  of  this  is  the  following:  There  are  a  non-disjoint 
categories  of  memo  objects.  An  object  n  beongs  to  the  i-th  category  if  xisTRUE. 
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the  sue  set  of  tickets ,  contained  in  file  dip,  and  still  hare  different 
privileges.  As  we  will  see  next,  the  situation  is  quite  different  under  the  AC 

ease. 

Under  the  AC- scheme,  we  assume  that  the  operator  read  demands  that  the 
right  "read”  is  in  the  operand-ticket.  Since  all  subjects  involved  must  have 
the  right  to  invoke  read .  the  difference  between  the  subjects  can  only  be  in 
terms  of  the  memo-tickets,  each  with  the  "read"  right,  which  are  available  to 
them.  Thus,  the  desired  policy  can  be  established  as  follows: 

For  a  given  memo-object  m,  let: 

Z(m)  s  {z1,...,zj}  4SX 

be  the  set  of  boolean  attributes  satisfied  by  a.  Let  target(m)  be  the  set  of 
subjects  S  such  that  for  each  of  them 

I(S)r>  Z(m) . 

This  is  exactly  the  set  of  subjects  which  by  our  policy  should  be  allowed  to 
read  m.  Therefore,  the  ticket  (m:memo;resd)  should  be  available  to  these 
subjects  and  to  none  other.  In  order  to  establish  such  a  distribution  of 
tiokets,  we  suppose  that  every  subject  S  in  our  system  has  a  file,  memos(S), 
which  is  readable  only  by  him.  Whenever  a  new  memo-object  m  is  created,  a 
non-convable  ticket  (m;memo;read)  should  be  stored  in  memos(S)  for  every  S  in 
target(m),  and  in  nowhere  else.  This  is  essentially  the  solution  given  by  Jones 
and  Wolf  to  a  similar  problem  [Jon75]. 

Let  us  now  compare  the  control-material  which  is  necessary  for  these  two 


implementations  of  our  policy: 


As  to  the  volume  &£  the  control  material,  suppose  that  there  are  NS 
subjects  in  a  system,  and  H  memo-objects.  Let  K  be  the  average  number  of 
subjects  which  are  allowed  to  read  a  memo-object.  The  AC  implementation 
requires  K*M  memo- tickets  to  be  stored  in  the  system,  while  under  the 
OC-representation  only  M  tickets  are  required.  (Also,  the  AC  implementation 
needs  NS  tickets  for  the  operator  read,  which  is  comparable  to  the  NS  activators 
needed  under  our  scheme) . 

Even  more  important  than  the  volume  of  the  control  material,  is  the 
complexity  of  its  distribution.  The  AC-implementation  requires  a  very  specific 
distribution  of  the  memo-tickets  among  the  NS  files  memos(S).  This  distribution 
of  tickets  is  itself  a  formidable  task.  Moreover,  every  file  memos(S)  must  be 
well  protected,  and  readable  by  the  specified  subject  S  only. 

The  situation  under  the  OC  implementation  is  much  simpler:  Once  the  NS 
different  read-activators  are  correctly  distributed  among  the  various  domain,  we 
can  store  all  the  M  tickets  In  one  file,  which  is  readable  by  everybody  and  does 
not  have  to  be  especially  protected.  This  is  obviously  much  less  complex  than 
under  the  AC-implementation. 


Stability  of  the  control  material :  Stability  is  a  very  desirable  property 
of  the  control  material,  for  a  number  of  reasons: 

a)  The  maintenance  of  highly  volatile  control-material  may  take  a  lot  of 
effort,  particularly  whenever  it  is  Involved  with  revocation. 

b)  The  probability  for  making  mistakes  in  the  distribution  of 
o  on  tiro  1- objects  Increases  with  their  volatility. 
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e)  Stability  of  the  control-material  facilitates  compile-time  checking. 

Ha  will  argue  that  the  control-material  tends  to  be  more  stable  (less  volatile) 
under  our  OC-scheme.  This  is  due  mainly  to  the  following  reasons: 

a)  Volatility  clearly  increases  with  the  complexity  and  the  volume  of  the 
control-material ,  which  tends  to  be  higher  under  the  AC  scheme. 

b)  There  is  a  difference  between  the  life  time  of  tickets  and  activators. 
A  ticket  (b;r)  cannot  exist  prior  to  the  creation  of  object  b,  or  after  its 
destruction.  An  activator  <o,[t]>,  on  the  other  hand,  can  live  as  long  as 
the  operator  o  and  the  type  t  exist;  the  meaning  of  this  activator  does 
not  depend  on  the  existence  of  any  particular  t-objects.  Thus,  an 
implementation  of  a  policy  under  a  AC  scheme,  which  is  based  entirely  on 
tickets,  has  an  a  priori  temporary  nature,  and  is  therefore  likely  to  be 
relatively  volatile. 

Moreover,  the  variations  in  control-material  which  do  exist  under  the  OC-scheme 
tend  to  concentrate  in  the  transient  part  of  domains,  while  their  permanent 
part,  which  contains  mostly  activators,  is  relatively  stable.  This  is  important 
because  it  is  mostly  the  permanent  part  of  the  domain  of  a  subject  which 
determines  bis  authority  (cf.  section  3.6).  He  will  now  Illustrate  some  of 
these  observations  in  the  context  of  our  memo-example.  He  start  by  examining 
folatllitT  under  a  fixed  policy,  the  one  presented  in  section  k.3«1,  when  the 
population  of  memoranda  is  changing. 

Under  our  OC  scheme,  each  subject  S  has  an  activator  which  determines  the 
type  of  memo-objects  which  can  be  read  by  him.  This  gives  S  a  general  authority 
with  respect  to  memoranda,  which  is  independent  of  the  particular  memo-objects 


in  the  system.  Indeed,  no  change  is  necessary  in  the  domain  of  S  when  new 
memo-objects  are  generated  or  when  existing  ones  are  deleted  or  changed.  The 
authority  makeup  of  S  is  stable  under  such  changes.  On  the  other  hand,  under 
the  AC- implementation  of  this  system,  whenever  a  new  memo-object  is  created  its 
tickets  must  be  given  to  all  subjects  who  are  allowed  to  read  it.  Even  worse, 
when  some  of  the  attributes  xi  of  m  are  changed,  the  tickets  of  m  may  have  to  be 
revoked  from  those  subjects  which  are  not  to  be  allowed  to  read  it  any  longer. 
Thus  the  control  material  must  be  constantly  changed  to  maintain  the  given 
policy. 

<  •.  i  Next,  let  us  consider  volatility  under  incremental  policy  change.  Using 
again  the  memo-system,  suppose  that  in  addition  to  read  there  is  another 
operator,  update,  whose  primary  activator  under  the  OC  mechanism  is: 

<update,[memo],  [text]>. 

Suppose,  also,  that  the  set  of  memoranda  that  a  subject  is  allowed  to  read  may 
be  different  from  the  set  he  is  allowed  to  update.  For  example,  S  may  have  the 
following  two  activators: 

<read , [ memo ; xi ] > 

<update,[memo;;x1],  [text]> 

This  means  that  S  can  read  and  update  memos  which  satisfies  xi. 

Now,  suppose  that  we  wish  to  change  this  policy  allowing  S  to  update  only 
memos  which  satisfy  both  xi  and  x2.  All  we  have  to  do  is  to  replace  his 
update-activator  with 

< update, [ memo ;;x1&x2],  [text]> 
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For  the  AC  case,  suppose  that  all  the  subjects  have  tickets  which  allow 
thee  to  .  call  both  read  and  update,  and  that  the  operator  update  requires  the 
right  "update"  ft* cm  its  argument  just  as  read  requires-  the  right  "read”. 
Initially  s  oust  have  access  to  the  set  of  tickets 

{ (■; read .update) |  m-satisfies-xlj 

for  all  nemos  which  satisfy  xl .  To  change  the  privileges  of  S  as  above  ns  must 
replace  all  his  memo-tickets  with  the  two  sets 

Cl  «  t(m;  update)!  m-statisfies-x1-and-x2} 

C2  *  {(m;  read)  I  m-satisfies-xlj 

Thus,  the  same  policy  change  which  requires  the  replacement  of  a  single 
activator  under  a  0C  scheme  requires  the  replacement  of  many  tickets  under  AC 
seheme. 

1*1*2  Efficiency  si  enforcement;  Two  factors  effect  the  enforcement 
efficiency: 

a)  The  complexity  of  the  computation  which  is  necessary  for  the  validation 
of  a  given  operation. 

b)  The  degree  to  which  validation  can  be  performed  at  compile-time. 

He  already  saw  that  the  enforcement  mechanism  which  is  necessary  to  support  the 
0C  scheme  is  essentially  identical  to  that  of  the  AC  scheme.  In  both  cases,  the 
operands  must  bechecked  against  the  operand-patterns  of  the  given  activator, 
which  is  the  "template”  in  the  case  of  Hydra.  Of  course,  the  complexity  of  such 
parameter  checking  depends  on  the  complexity  of  the  activation  patterns.  Our 
aeheme  allows  for  essentially  arbitrarily  complex  patterns,  but  it  does  not 
recuire  such  complexity.  If  the  0C  scheme  is  used  for  the  protection  of 
operating  systems,  one  would  probably  impose  severe  restrictions  on  the  syntax 
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and  semantics  of  activation-patterns  and  of  G.  Much  more  general  patterna  can 
be  used  in  the  context  of  information-systems ,  without  a  significant  relative 
increase  in  the  overhead  due  to  protection. 

As  to  the  second  factor  which  affects  efficiency  of  enforcement,  we  claim 
that  our  scheme  facilitates  compile- time  validation,  due  to  the  greater 
stability  of  its  control-mterial .  In  particular,  it  appears  that  the  compiler 
can  do  much  of  the  necessary  checking  by  analyzing  the  relatively  static 
"permanent-part"  of  the  domain  of  a  subject.  However,  more  study  is  necessary 
to  substantiate  this  claim. 

CONCLUSION 

The  operation-control  (OC)  scheme  introduced  in  this  paper  is  a  natural 
generalization  of  the  capability-based  version  of  the  access-control  (AC)  scheme 
developed  for  operating  systems.  This  generalization  is  achieved  by  the 
introduction  of  the  activators,  which  play  an  analogous  role  to  that  of  the 
tickets  under  the  AC  scheme,  and  which  do  not  require  any  new  enforcement 
effort.  The  use  of  activators  together  with  tickets  has  a  profound  effect  on 
the  authorization  scheme:  The  representation  of  complex  policies  becomes  easier 
and  more  natural.  The  control-material  which  is  necessary  for  the 
representation  of  policies  tends  to  be  less  voluminous,  less  complex  and  more 
stable.  The  stability  of  the  control-material  reduces  the  need  for  revocation, 
and  facilitates  compile-time  enforcement.  It  is  also  believed  that  this 
stability  and  simplicity  of  the  control  material  would  facilitate  the  proof  of 
policies,  it  should  be  pointed  out,  however,  that  the  proposed  scheme  has  yet 
to  prove  itself  in  the  context  of  a  real  system.  There  is  work  in  progress 
which  attempts  to  base  the  protection  of  information  systems  on  this  scheme. 
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Figure  2 

Activators  in  a  domain  arc  portrayed  here  as  kind  of  enzymes  in  the  living 
cell.  The  activator  A1  is  depicted  as  if  it  is  attached  to  the  objects 
qi.  q2  which  match  its  operand -patterns.  The  object  qo,  which  matches  the 
outcome  pattern  po  of  A1  is  being  generated.  Note  that  qo  can  be  attached 
to  the  operand  pattern  of  A2  and  that  the  outcome  of  A2  would  fit  the 
pattern  p2  of  Al.  The  small  circles  represent  various  objects  in  the 
domain  and  the  small  patterns  attached  to  them  represent  their  type,  facade 


and  rights. 


READ1 


UPDATE 1 


ERASE 


-  (fl :file) 

-  (f2 : f ile) 

■  ^ctdoc,  [f  1] ,  [text^  -*•  [doc;u] 

■  ^etdoc  ,  [f  2]  ,  [text]^  ■*  [doc ; E ; slcvel= 1 ] 

«  ^ead,  [doc;  ;slevel<2]> 

«  Update, [doc ;u; category ="navy * ] , [text]^ 

■  ^rase,  [doc;E]> 


Figure  3:  The  permanent  part  of  a  domain 

It  contains  two  file  tickets  and  five  activators.  GET'  and 
GET"  can  operate  on  the  file  tickets,  generating  doc-tickets 
into  the  transient-part  of  the  domain.  The  last  three 
activators  operate  on  these  doc-tickets. 


The  solid  arrows  represent  sequence  of  derivation  of  activators.  The 
dashed  arrows  represent  dependency  of  the  activator  on  the  boolean 
variables  al,  a2. 


To  be  published  in  the  Assoc,  of  the  COMPSAC  77  Conference,  November,  1977. 
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ABSTRACT 

Hm  eaerging  technology  of  distributed  computing,  and  the  growing  trend  of 
oonputerlzation  of  large  systems  necessitates  a  technique  for  distributed  and 
aooperative  authorization  and  control.  For  example,  a  large  financial 
transaction  in  a  distributed  electronic-fund-transfer  (EFT)  system  may  require 
the  independent  approval  of  several  subjects,  an  authorization  scheme  which 
can  support  such  a  cooperation  is  descried.  It  is  based  on  the 
operation- control  scheme  recently  developed  by  this  author. 
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1 :  INTRODUCTION 

Authorization  in  computer  aysteas  is  a  discipline  under  which  an  action  on 
the  system  can  be  carried  out  by  a  user  ,  or  by  one  of  the  modules  of  the 
ayatea .  only  if  the  actor  is  authorized  to  perform  this  action.  Such  a 
discipline  facilitates  the  reliability  of  coaputer  systems  and  is  the  basis  for 
their  protection.  Cooperative  authorization  has  to  do  with  actions  which  have 
to  be  authorized  by  several  subjects,  independently.  There  are  many  real  world 
situations  which  require  such  authorization.  For  example,  the  transfer  of 
large  sums  of  money  from  one  account  to  another,  or  the  release  of  sensitive 
'  information  frequently  requires  the  approval  of  several  subjects.  Another, 
unpleasant  example  for  the  need  of  cooperative  authorization  is  the  launching 
of  nuclear  weapons. 

Cooperative  authorization  is  essential  in  computer  systems  due  to  the  ever 
VZicreasing  trend  of  computerization  of  large  systems ,  such  as 
informatin-systeos ,  financial  systems,  medical  systems,  etc.  The  importance  of 

such  authorization  is  further  enhanced  due  to  the  emerging  technology  of 

»' 

distributed  computing,  which  facilitates  applications  such  as  the  "electronic 
fund  transfer".  Unfortunately,  in  spite  of  the  considerable  interest  in 
authorization  and  protection,  cooperative  authorization  has  not  been  studied 
systematically. 

The  purpose  of  this  paper  is  to  introduce  the  issue  of  cooperative 
authorization,  and  to  suggest  some  techniques  to  support  it.  Our  discussin 
mill  be  in  the  context  of  the  operation-control  (OC)  scheme  recently  developed 
by  this  author  [1,2].  He  start  with  an  informal  and  partial  overview  of  this 
scheme ,  its  use  for  cooperative  authorization  is  discussed  in  section  3* 


2:  THE  OPERATION-CONTROL  (OC)  SCHEME 

The  OC  scheae  for  authorization  ia  a  generalization  of  the 
capability-based  version  of  the  access-control  scheae  [3;*].  He  start -with  a 
brief  review  of  the  OC  scheae  Soae  extentions  to  it,  which  are  necessary  for 
oooperative  authorization  are  introduced  towerds  the  end  of  this  section. 

A  computer  system  changes  in  tioe  due  to  instructions  issued  by  subjects . 
where  an  instruction  is  a  request  to  apply  an  operator  to  a  sequence  of 
objects-its  operands.  The  authority  of  a  subject  is  defined  as  the  set  of 
instructions  which  can  be  carried  out  by  him.  In  our  scheae  this  authority  is 
determined  by  the  content  of  the  "domain"  of  a  subject.  A  domain  D(S)  is  an 
object  uniquely  associated  with  the  subject  S  which  serves  as  the  address-space 
of  S.  Namely,  objects  contained  in  D(S)  are  directly  addressable  by  S,  and 
these  are  the  only  such  objects.  However,  a  domain  may  contain  special  objects 
called  "tickets"  which  serve  as  pointers  to  "sharable  objects"  which  do  not 
reside  in  any  domain,  but  can  be  shared  by  several  subjects  (•).  In  contrast 
to  such  sharable  objects,  the  objects  which  physically  reside  in  a  domain  are 

f 

called  "concrete  objects".  These  include  in  particular  tickets  of  sharable 
objects. 

The  main  building  blocks  of  authorization  under  the  OC  scheme  are  objects 
of  type  activator.  An  activator  has  the  foro(*) 

(•)Our  tickets  are  equivalent  to  the  "capabilities"  of  the  access-control 
scheae  [3,4].  Note  that  in  addition  to  an  object  identifier,  a  ticket  usually 
contains  "rights"  with  respect  to  this  object.  However,  for  simplicity  we  will 
not  use  such  rights  in  this  paper. 


(••)This  is  a  simplified  fora  of  activators,  see  [1]  for  the  complete  fora 
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wbere  a  is  an  operator  identifier,  and  pi  for  isl,...,k,  are  conditions  on  the 
operands  of  o,  which  are  called  the  "operand  patterns"  of  the  activator.  The 
existence  of  such  activator  in  the  domain  D(S)  serves  as  a  permission  for  S  to 
apply  operator  a  to  a  sequence  of  objects  q1,...,qk  in  D(S)  ,  which  "match"  the 
respective  activation  patterns  (or  satisfy  the  conditions)  p1,...,pk  .  As  a 
notatlonal  devise ,  we  will  give  a  name ,  say  "A" ,  to  an  activator  by  writing 


A  *  <o,p1 ,pk> 


When  an  activator  A  is  used  to  authorize  the  invocation  of  o(q1,...,qk)  we  will 
say  that  the  activator  A  is  applied  to  the  objects  q1,..,qk,  denoting  such  an 
application  by  A(q1 «...  ,qk). 

An  operand  q  which  is  matched  with  an  operand-pattern,  may  be  either  a 
concrete  object  which  stands  for  itself,  such  as  an  integer  number,  or  it  may 
be  a  ticket  of  a  sharable  object,  which  is  the  real  operand.  In  both  cases,  we 
will  refer  to  q  as  an  operand,  relying  on  the  context  to  resolve  the  ambiguity. 


An  operand  pattern  p  of  an  activator  has  the  form 


ClSiV] 


where  I  is  a  condition  on  the  type  and  identity  of  the  operand,  and  V  is  a 
condition  on  its  value.  Instead  of  defining  these  components(*)  of  a  pattern 
we  will  give  a  number  of  examples: 

(*)The  pair  Indicates  a  missing  part  in  the  more  general  form  of  the 
pattern  introduced  in  [1]. 
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Let  doe  be  a  type  of  objects  which  carry  documents  in  a  military 
information  system.  Suppose  that  in  addition  to  the  document  itself  a 
doc-object  has  two  components:  "slevel" ,  which  represents  the  "security  level" 
of  the  document,  and  "category"  which  represents  its  category,  such  as  "navy" 
or  "army".  Let  read  be  an  operator  which  displays  the  contents  of  a  document. 
Consider  the  following  activators  for  read .  or,  "read-activators": 


I  *  ^read  ,[doc]^ 

!|  HI  s  ^read  ,[d:doc^ 

Ml  *  ^read,[d:doe  ;;  slevel<3  3^ 

H2  *  ^read,[doc  ;;  slevel<2  ] ) 

^  H21  *  ^*ead,[doc  ;;  slevel<2  &  category* "navy*  ] } 


The  activator  R  can  be  applied  to  any  document;  R1  can  be  applied  only  to  the 
specific  document  4;  R2  can  be  applied  to  any  document  whose  slevel<2;  R21 
can  be  applied  to  any  "navy"  document  whose  slevel<2;  finally,  R11  can  be 
applied  only  to  document  4,  provided  that  its  slevel  is  smaller  than  3. 

Rote  that  all  these  read-activators  are  different  from  each  other.  In  a 
sense,  they  have  different  power.  In  order  to  compare  the  power  of  different 
o-aotivators  for  a  given  operator  &,  we  now  Introduce  a  number  of  concepts. 

Let  A  be  an  activator  of  order  k  (with  k  operand-patterns).  He  define 
rangc(A)  to  be  the  set  of  all  possible  k-tuples  (q1,...,qk)  of  objects,  which 
can  be  matched  with  the  corresponding  activation-patterns  of  A. 


Let  A  and  A'  be  two  o-activators  for  a  given  operator  .o.  We  will  say  that 
A*  la  weaker  than  A  (or,  equivalently,  A  is  stronger  than  A*)  iff 


range(A')  ^range(A) 
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•)  An  activator  A  nay  have  a  uaaaef)  attribute  u(A).  If  this  attribute 
exists  it  sets  a  limit  on  the  number  of  applications  of  A.  (An  activator 
whose  usage  component  is  one  will  be  called  a  non- re usable  activator) .  In 
oonclusin  we  would  like  to  reiterate  that  in  a  system  based  on  the  OC 
scheme  no  action  can  be  performed  without  an  appropriate  activator. 
Moreover,  it  should  be  emphasized  that  the  generation  and  transport  of 
' '  activators  is  tightly  controlled  so  that  the  ownership  of  an  activator  A  by 
a  subject  S  can  serve  as  an  incontestable  proof  that  S  is  authorized  to 
perform  any  action  enabled  by  A. 

So  much  for  the  oc  scheme,  as  it  is  defind  in  [1],  We  will  now  introduce 
two  minor  extensions  to  it. 

Extension  1 :  The  application  of  an  activator  A  is  a  complex  indivisible 
operation  which  consists  of  the  binding  of  operands  to  the  operand  patterns  of 
L ,  and  then  the  invocation  of  the  operator  Q.  addressed  by  A.  We  will  now  allow 
for  the  separation  of  these  two  parts  of  the  application  of  activators,  as 
follows: 

ft 

first,  we  introduce  the  operator 

bind(A,i  ,q) 

which  binds  the  object  q  to  the  i-th  pattern  pi  of  activator  A,  provided  that  q 
matches  this  pattern.  This  operation  has  a  permanent  effect  on  A  and  on  q,  in 
the  following  sense:  Once  an  object  q  is  bound  to  ua  activation  pattern  pi  by 

(••)The  "usage"  facility  has  been  introduces  in  (1]  but  in  a  different  form. 
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tb«  operator  bind .  it  cannot  be  removed  from  it.  This  means  that  q  is  not  free 
for  use ,  and  that  the  pattern  pi  of  A  cannot  be  bound  to  any  other  object. 
This  is  in  contrast  to  the  indivisible  application  of  an  activator,  which 
leaves  the  patterns  free  to  be  bound  to  other  objects  on  successive 
applications  of  the  activator.  Accordingly,  binding  by  means  of  this  operator 
will  be  called  "permanent  binding". 

How  cosider  the  activator 

A  *  <o ,£l,...  iQii,...  ,pn  > 

whose  patterns  p1,...,pk  are  permanently  bound.  (To  distinguish  between  bound 
and  unbound  patterns  we  underline  the  formers).  Such  an  activator  can  be 
applied  tc  objects  q(k+1) ,...  ,qn  which  will  be  bound  (not  permanently)  to  the 
still  unbound  patterns  p(k*1) ,...  ,pn.  In  the  special  case  of  k=n ,  namely  when 
all  the  patterns  are  permanently  bound,  the  application  of  the  activator  is 
simply  the  invocation  of  the  operator  a  on  the  already  bound  operands. 

e,  For  the  purpose  of  permanent  binding  we  will  allow  for  limited  sharing  of 
activators  as  follows:  An  activator  A  which  resides  in  a  domain  D(S)  may  be 
shared  by  several  subjects  who  can  bind  operands  to  it.  However,  only  the 
subject  S  who  has  A  in  his  domain  can  actually  apply  it. 

Ex  tension  Ai.  Given  an  activator 

A  •  <o,p1 «...  ,pk  > 


Ki  will  allow  for  the  following  derivative  of  A: 
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A*  *  <o,p1 ,pk,p(k+1)... ,pn  >. 


A'  is  identical  to  A  except  that  it  has  n-k  new  operand  pattern.  A'  will  be 
oosidered  weaker  than  A  because  it  imposes  stronger  requirements  on  the 
Invocation  of  the  operator  o,  namely,  the  availability  of  objects  q(k+1 ) . .  ,qn 
which  match  the  new  patterns. 


3:  COOPERATIVE  AUTHORIZATION 


Consider  a  subject  SI  who  has  the  o«activator 


A  *  <o,p1 ,...  ,pk  > 


in  his  domain  but  who  does  not  have  a  complete  sequence  of  objects  ql,...  ,qk 
which  fit  the  respective  patterns  p1,...,pk  of  A.  Suppose  ,  however,  that  such 
a  sequence  exists  in  the  union  of  the  domains  of  the  subjects  S1,...,Sn.  It  is 
dear  that  SI  by  himself  cannot  apply  A,  but  A  can  be  applid  by  means  of 
cooperation  between  all  the  subjects  SI,...,  Sn.  One  can  think  of  two  basic 
modes  of  such  a  cooperation: 

First,  the  subjects  S2,...,Sn  may  give  SI  the  objects  he  needs  for  the 
application  of  A.  Unfortunately,  this  simple  mode  of  cooperation  has  the 
following  serious  drawback:  Let  S2  be  a  subject  which  gives  SI  the  object  q2 
which  is  necessary  for  the  application  of  A.  The  problem  is  that  SI  may  have 
several  activators  which  can  be  applied  to  q2,  so  th£t  S2  has  no  way  of  knowing 
how  would  his  object  q2  be  actually  used  by  SI.  Such  a  cooperation  may 
therefore  be  dangerous  for  S2. 


The  second  node  of  cooperation  which  does  not  suffer  from  the  above 
problem ,  is  the  following:  SI,  who  wishes  to  apply  the  o-activator  A,  first 
creates  the  weakest  reduction  A'  of  A  which  still  suits  his  purpose.  A'  is  now 
given  to  each  of  the  subjects  S2,...,Sn  who  are  asked  to  make  their 
contribution  by  binding(*)  one  or  aore  operands  to  the  operand-patterns  of  A'. 
This  binding  is  permanent .  which  means  that  an  object  q  bound  to  a  pattern  p  of 
A  cannot  be  misused  by  SI  since  it  cannot  be  freed  from  this  binding  and  cannot 
be  used  for  any  other  purpose.  Moreover,  each  of  these  subjects  can  examine 
all  the  patterns  of  A'  and  the  operands  already  bound  to  them,  if  any,  so  that 
he  has  a  way  to  know  the  nature  of  the  action  in  which  he  cooperates.  Note 
that  the  degree  of  knowledge  that  each  of  the  cooperating  subjects  has  about 
this  action  depends  on  the  degree  of  specificity  of  the  oprand-patterns  of  A' . 
That  is  why  it  is  important  for  SI  to  create  the  weakest  possible,  the  most 
specific,  activator  A'.  If  A'  is  not  weak  enough  some  of  the  subjects 
^~S2,...,Sn  may  refuse  to  cooperatie  in  its  application.  This  mode  of 
cooperation  will  now  be  illustrated  by  means  of  two  examples. 

1.1;  Iha  Signature  Example 

t 

Let  acc  be  a  type  of  objects  which  represent  accounts  in  a  computerized 
financial  system.  Suppose  that  the  only  operator  which  can  change  the  amount 
of  money  in  an  account  is  the  operator  move  whose  primary  activator  is  (••) 

MOVE  *  ^nove , amount :[int] ,  froo:[acc]  ,to:[acc] 

(*)Note  that  this  binding  can  be  done  in  parallel,  if  the  subjects  S2,...,Sn 
■share"  the  activator  A* . 

(••)The  phrase  "amount :( int] " ,  gives  the  label  "Amount"  to  the  associated 
pattern.  Such  a  label,  which  is  used  only  for  discussion,  is  optional. 


The  operation  M0VE(k,a1  ,a2)  moves  k  dollars  from  account  al  Into  a2,  (thus 
preserving  the  total  amount  of  money  In  the  system^"*)  ). 

The  activator  MOVE  Is  very  powerful,  since  it  can  be  used  to  move  money 
between  any  two  accounts.  We  assume,  however,  that  there  is  just  one  copy  of 
MOVE  In  the  system,  contained  in  the  domain  of  the  account-generator.  It  is 
also  assumed  that  together  with  an  account  &.1 ,  the  account-generator  creates 
the  following  derivative  of  MOVE: 

MOVE-al  s  ^nove,...  ,from:[al:acc] 

The  only  difference  between  MOVE  and  MOVE-al  is  that  the  "from"  pattern  in  the 
latter  can  be  matched  only  to  the  specific  account  al.  Thus,  MOVE-al,  which  is 
weaker  than  MOVE,  can  be  used  to  move  money  from  to  an  arbitrary  account. 

Rest ,  let  us  introduce  the  type  signature.  A  signature-object ,  or  simply 
signature,  is  an  object  which  contains  the  identifier  of  the  subject  which 
generated  It.  A  signature  can  be  generated  only  by  means  of  the  operation 

f- 

sign(A,i) 

which  creates  a  new  signature  and  binds  it  to  the  1-th  pattern  of  activator  A. 
thus, in  effect,  "signing"  the  activator  A.  Of  course,  this  can  be  done  only  if 
the  i-th  pattern  of  A  matches  the  signature  of  the  subject  who  invokes  the 
operation  above.  Note  that  a  signature  thus  defined  has  no  free  exlstance  in 


(•••)To  represent  flow  of  money  into  and  out  of  the  system  dnc  „*an  introduce 
special  "source"  and  "sink"  accounts  (see  [2]). However,  we  will  not  be 
concerned  with  this  issue  here. 
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the  system  because  its  generator  always  binds  it  permanently  to  some  activator. 

Mow,  suppose  that  the  subject  S,  who  generated  a  certain  account  al , 
decides  that  every  removal  of  money  from  al  must  be  approved  by  two  subjects  SI 
sod  S 2.  This  policy  can  be  enforced  as  follows.  Suppose  that  S  replaces  his 
MOVE-al  activator  with  the  following  reduction  of  it. 

MOVE-al'  =  -^nove  ,[int] f[a1:acc] ,[acc] , 

[signature; ;S1 3 .[signature; ;S2] ^ 

This  activator  contains  two  new  patterns  which  match  only  signatures  of  SI  and 
S2 ,  respectively.  Thus,  every  removal  of  money  from  al ,  which  requires  the 
application  of  MOVE-al*  or  of  one  of  its  derivatives,  must  be  endorsed 
explicitly  by  the  signatures  of  SI  and  S2.  One  can  imagine  the  following 
sequence  of  events  which  leac  to  the  application  of  MOVE-al*:  A  subject  S*  who 
wishes  to  move  k  dollars  from  al  to  a2,  generates  the  following  non-reusable 
reduction  of  MOVE-al* 

MOVE-al"  s  ^move,[int; ;val=k]  ,[a1:acc]  ,[a2:acc]  , 

[signature; ;S1]  .[signature; ;S2 ) 

which  can  be  used  only  to  move  j£  dollars  from  £.1  into  a  specific  account  &2. 

t 

This  activator  is  now  sent  to  SI  and  S2  for  approval.  Each  of  these  subjects 
can  examine  this  activator,  and  if  he  approves  of  the  Implied  transaction  he 
would  endorse  it  by  "signing"  the  appropriate  pattern.  Once  the  activator  is 
signed  by  both  subjects  it  can  be  applied  to  the  operands  k,a1,  and  a2.  Note 
that  SI  and  S2  can  sign  the  activator  in  parallel,  if  they  share  it. 

A  number  of  variations  of  this  approval  process  are  possible.  He  will 
mention  two  of  them.  First,  the  subject  SI  and  S2  may  be  ready  to  approve  a 
more  general  transaction  than  the  move  of  k  dollars  from  al  to  a2.  For 
example ,  they  may  be  ready  to  sign  the  activator 
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<§iove,[int;;valsk]  ,[a1]  ,[acc] 

which  can  be  used  to  move  k  dollars  from  al  to  any  account.  The  point  is  that 
SI  and  S2  can  exaaine  the  activator  before  they  sign  itt  so  that  each  of  them 
knows  what  kind  of  action  he  approves. 

A  second  variation  of  our  exaaple  is  the  following.  Suppose  that  every 
signature-object  created  by  a  subject  S  is  a  pair  (S,l)  where  S  is  the 
Identifier  of  the  subject,  as  above,  and  2  is  its  "signature-level”.  the 
signature-level  is  a  number  associated  with  a  subject  which  reflects,  in  some 
sense,  his  importance  as  an  officer  in  the  corporation.  Now,  one  may  require 
that  a  transaction  be  approved  by  the  signature  of  one  or  more  subjects  with  a 
given  signature-level,  which  is  a  very  common  requirement  in  banking.  For 
example,  the  activator. 

^tove,... ,[ signature  ;;  levels?  ] ^ 
cannot  be  applied  without  a  signature  whose  level  is  at  least  2. 


(•)Tbis  example  has  been  chosen  for  its  intuitive  appeal.  Unfortunately  the 
exaaple  Implies  a  snaewhat  unrealistic  degree  of  cooputarization  of  health 
management.  However,  it  is  easy  to  find  more  realistic  examples  which  have 
similar  authorization  structure. 
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The  act  of  selling  a  drug  to  a  patient  Is  Involved  with  a  fairly  complex  t 
cooperative  authorization  procedure.  Three  subjects  actively  cooperate  In  this 
act.  First ,  there  is  a  doctor  £  who  gives  a  prescription  for  a  specific  drug  4 
to  patient  J*.  This  prescription  serves  as  an  authorization  for  P  to  buy  the 
drug  d.  Moreover,  the  prescription  may  serve  as  an  authorization  to  charge  the 
drug-prescription-program  of  P  for  the  prescribed  drug.  Next,  the  patient  can 
bring  the  prescription  to  a  pharmacy  of  his  choice.  The  pharmacist,  who  has 
access  to  drugs  but  no  rights  to  sell  them  to  specific  people,  is  thus 
authorized  to  sell  to  patient  P  a  drug  which  fits  the  doctor's  prescription, 
(lote  that  the  doctor  may  specify  the  chemical  name  of  a  drug,  leaving  it  up  to 
the  pharmacist  to  choose  a  brand  name). 

For  the  sake  of  this  example,  imagine  that  there  is  a  robot  in  every 
computerized  pharmacy,  which  actually  gives  drugs  to  customers.  This  robot  can 
be  activated  only  by  means  of  the  operator  sell  whose  primary  activator  is 

SELL  »  ^ell , [drug]  ,[ patient]  ,[acc]  ^ 

A 

As  we  will  see  below,  this  activator  is  equivalent  to  a  blank  prescription 
form,  and  we  assume  that  only  doctors  have  copies  of  it. 

Mow,  a  doctor  creates  the  equivalent  of  a  prescription  by  generating  the 
following  reduction  of  SELL 

SELL'  *  ^sell,[drug;  ;cname]  ,[ji)  ,[acc]^ 

The  first  operand-pattern  of  SELL'  matches  only  drugs  whose  *  chemical  name  is 
onase,  while  its  second  pattern  is  bound  to  a  ticket  p  of  a  specific  patient  P. 
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This  "prescription"  is  now  given  to  P  who  binds  its  third  pattern  to  the  ticket 
of  aone  account  ac .  This  nay  be  a  general  purpose  accont ,  such  as 
Bankaaericard ,  or,  it  may  be  the  patient's  prescription- program  accont.  The 
resulting  activator  is  now  given  to  some  pharmacy.  There,  finally,  SELL'  is 
app)  led  to  a  drug  whose  chemical  name  is  cname,  giving  P  his  drug  and  charging 
the  account  as.  for  It. 

Mote  that  the  real-world  policies  with  respect  to  selling  of  medicines 
Impose  some  additional  restricions.  First  the  "prescription"  SELL'  given  by  a 
doctor  to  his  patient,  must  be  uncopiable,  although  it  should  be  transferable. 
Moreover,  it  should  be  unreusable,  or  at  least  it  should  have  a  finite  usage . 
which  is  equivalent  to  the  number  of  refills  allowed  by  the  doctor. 

4:  CONCLUSION 

This  paper  discussed  the  issue  of  cooperative  authorization  purely  in  the 
context  of  the  OC-scheme.  It  would  be  more  difficult,  if  at  all  possible, 
to  base  such  authorization  on  the  conventional  access-control  scheme,  as  it 
appears  in  Hydra  [4]  for  example.  However,  some  recent  generalizations  of  the 
capability-based  scheme  [5 ,6] ,  which  features  more  complex  tickets  structure 
appear  to  facilitate  at  least  a  certain  degree  of  cooperative  authorization, 
although  the  authors  of  these  schemes  did  not  discuss  such  authorization 
explicitly. 
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The  Internal  control  of  a  financial  entity  is  based  on  complex, 
.sometimes  subtle,  system  of  authorization  and  capabilities  which  we 
mu  the  "authority  structure"  of  the  entity.  The  computerization  of  a 
financial  entity  carries  with  it  a  danger  of  the  breakdown  of  its 
authority  structure,  which  might  endanger  the  internal  control  of  the 
entity,  and  its  auditability.  It  is  our  thesis,  however,  that  with  a 
proper  use  of  authorization  and  protection  techniques  developed  for 
computer  systems ,  it  is  possible  to  impose  a  desired 
authority-structure  on  a  computerized  financial  entity.  The 
feasibility  of  such  computer  based  authorization  and  its  ramification 
for  auditing  are  the  subjects  of  this  paper. 
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li  Introduction 

The  auditor's  analysis  of  a  system  depends  to  a  large  extent  on 
his  knowledge,  or  beliefs,  about  its  "authority  structure".  By  this  we 
mean  the  authority  and  capabilities  of  the  various  actors,  or  subjects, 
which  play  active  roles  with  respect  to  the  system.  For  example,  the 
reliance  of  the  auditor  on  any  documentary  evidence,  such  as  the  audit 
trail,  depends  on  his  belief  that  the  subjects  who  might  have  any 
interest  in  forging  documents,  .  did  not  have  any  access  to  them. 
Indeed,  the  authority  structure  of  a  system  is  the  linchpin  of  its 
"internal  control"  and  it  provides  the  basis  for  concepts  such  as 
segregation  of  duties,  and  for  tools  such  as  the  audit  trail. 

The  nature  of  the  authority  structure  of  non-computerized 
financial  systems  is  well  understood.  The  authority  structure  of  a 
gw~en  system  can  be  determined  by  means  of  questionnaires,  interviews, 
observation  of  personnel  and  review  of  documents  pertaining  to 
corporate  structure,  such  as  organization  charts,  etc.  There  are  well 
established  means  for  the  enforcement  of  adherence  to  authorization; 
they  include  physical  limitations,  legal  codes,  social  pressures,  and 
the  psychological  makeup  of  people.  There  is  even  some  knowledge  about 
the  ways  in  which  humans  are  likely  to  err  or  otherwise  commit 
improprieties,  as  well  as  the  circumstances  under  which  these  events 
can  take  place.  Actual  compliance  to  authorization  can  be  determined 
to  a  great  extent  by  observing  people  and  inspecting  records  using  the 


f 


audit  trail. 


The  Issue  which  will  concern  us  in  this  paper  is  that  the 
computerization  of  a  system  brings  with  it  the  danger  of  a  breakdown  of 
Its  authority-structure,  as  well  as  the  opportunity  for  tightening  it 
nPt  making  the  system  safer  and  more  auditable.  In  the  next  section  we 
will  explain  briefly  why  computerization  endangers  the  authority 
structure  of  systems.  Our  approach  for  avoiding  these  dangers,  and  for 
capitalizing  on  the  opportunities  of  computerization  are  discussed  in 
section  3 . 

breakdown  qL  £h§.  authority  structure  conventional 
computerized  systems 

The  prime  effect  of  computerization  is  that  much  of  the  activity 
of  the  system  is  performed  by  program  modules  (procedures,  subroutines, 
etc.)  rather  than  by  people.  This  might  seem  only  to  improve  the 
situation  because  one  can  rely  on  a  program  to  do  exactly  what  it  is 
programmed  to  do.  Unfortunately,  it  is  virtually  impossible  to  know 
exactly  what  every  one  of  the  hundreds  of  program-modules  of  a  system 
will  do  under  all  conceivable  circumstances,  even  under  the 
(unrealistic)  assumption  that  these  modules  themselves  are  not  being 
changed  during  the  time  period  studied  by  the  auditor.  Thus,  the 
auditor  must  treat  the  various  modules  of  the  system  as  black  boxes 
whose  internal  structure,  their  code,  is  partially  or  completely 
unknown. 

Now,  the  problem  is  that  if  we  do  not  know  exactly  how  a  given 
module  Is  programmed,  there  is  nothing  we  can  say  about  what  it  might 
do.  Potentially,  every  program-module  has  unlimited  power  with  respect 


to  the  data-base  maintained  by  the  system.  For  example,  a  module  that 
1.  designated  to  update  the  personnel  file,  might  actually  be 
(  programmed,  inadvertently  or  maliciously,  to  reach  the  accounts 
receivable  file,  changing  it  in  some  unpredictable  fashion.  As  another 
example,  the  auditor  may  be  told  that  certain  types  of  transactions 
!  leave  an  audit  trail,  stored  on  a  given  file  F.  He  might  even  be  able 
to  validate  this  claim  by  a  careful  study  of  the  module  which  carries 
out  the  transaction.  But  how  does  he  know  that  the  file  F  has  not  been 
changed  by  some  other  module  of  the  system?  In  a  manual  system,  the 
auditor  is  usually  able  at  least  to  identify  a  small  set  of  people  who 
are  physically  able  to  get  to  a  filing  cabinet,  but  in  the  computerized 
case  every  module  is  able  to  update  F .  Thus,  even  the  credibility  of 
the  audit  trail .  one  of  the  main  tools  of  auditors,  is  destroyed . 

A  similar  problem  exists  in  the  case  of  a  user,  which  is  a  person 
who  interacts  with  the  system:  He  is  not  restricted  by  many  of  the 
physical  restrictions  which  may  limit  his  power  in  a  manual  system. 
Unless  something  is  done  about  it,  the  user  would  have  virtually 
unlimited  power  with  respect  to  the  system  at  hand.  Moreover  the 
probability  of  sinister  use  of  this  power  is  enhanced  due  to  the 
following  two  reasons:  First,  a  user  who  interacts  with  a  computer  is 
not  inhibited  by  the  normal  social  pressures  which  exist  in  interaction 
between  people  (unless  he  suspects  that  his  interaction  with  the 
computer  is  recorded).  Secondly,  the  incentives  for  fraud  are  stronger 
in  a  computerized  system  due  to  the  high  degree  of  centralization  of 
resources.  The  procedures  that  would  inhibit  a  person  from  stealing 
$500  are  likely  to  be  less  effective  when  an  opportunity  to  steal 


JO, 000  presents  itself. 
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These  remarks  lead  to  the  conclusion  that  one  must  be  able  to 
impose  a,  priori  limitations  on  the  power  of  the  various  subjects 
(actors)  of  the  system,  whether  they  are  program  modules  or  people 
which  interact  with  them.  For  example,  a  program  module  P  which  is 
supposed  to  update  the  personnel  file  should  be  invested  with 
sufficient  authority  to  do  so.  However,  P  should  not  be  able  to  access 
the  accounts  receivable  file,  or  any  other  part  of  the  system  which  is 
irrelevant  to  its  function,  regardless  of  the  actual  code  in  P.  The 
discipline  which  allows  one  to  impose  such  restrictions  on  the  subjects 
of  computerized  systems,  is  called  "authorization  mechanism",  to  be 
discussed  next. 

3:  Authorization  in  computerized  systems .  and  its  use  for  auditing 

Conceptually,  an  authorization  mechanism  consists  of  two 
parts:  First,  there  is  the  authorization  scheme  which  is  a  formal 
language  which  allows  us  to  specify  the  authority  of  each  and  every 
subject  in  the  system,  whether  it  is  a  program  module  or  a  person. 
Secondly,  we  need  an  enforcement-mechanism  to  protect  the  system 
against  unauthorized  operations. 

The  following  example  illustrates  a  way  in  which  authorization 
could  impruve  the  auditability  of  systems.  We  will  be  using  the 
"operation  control"  authorization  mechanism  [1,2]  recently  develped  by 
the  author.  This  mechanism  and  its  possile  applications  will  be 
discussed  in  some  detail  in  the  full  paper. 

An  example :  One  of  the  most  important  types  of  entities  in  any 


financial  system  are  accounts.  An  account  might  represent  various 
items  like  assets,  liabilities,  revenues  (all  in  dollar  units)  and 
it  should  be  accessible  only  by  a  specified  set  of  subjects. 
Under  a  computerized  information  system.  The  accounts  would  be 
represented  simply  by  records  on  a  file,  and  in  the  absence  of 
authorization,  every  subject  would  be  apable  of  changing  the 
content  of  every  account,  in  an  arbitrary  way.  This  state  of 
affairs  must  raise  some  doubts  in  the  auditors  mind  as  to  the 
authenticity  of  the  accounts  which  he  reviews,  particularly, 
because  erroneous  or  malicious  changes  of  accounts  are  not  likely 
to  leave  any  audit  trail.  However,  using  the  OC  mechanism  it  is 
possible  to  establish  the  following  type  of  discipline,  (see  [1] 
section  2.8). 

1)  The  only  module  in  the  system  which  can  update  accounts  is  the 
procedure  move(a1 .a2.k)  which  moves  k  dollars  from  account  al 
to  a2,  leaving  the  total  amount  of  money  in  the  system 
unchanged.  To  represent  the  flow  of  money  into  the  system  we 
will  have  a  special  procedure  gen-account(k)  which  generates  a 
new  account  with  k  dollars  in  it.  To  represent  outflow  of 
money,  we  will  have  a  special  type  of  accounts  called  sinks 
which  have  the  property  that  money  can  flow  into  them  but  not 
back.  It  is  assumed  that  the  procedures  move  and  gen-account 
are  correctly  programmed,  and  that  they  are  designed  to  leave 
an  audit  trail  of  their  actions. 

2)  The  use  of  the  procedures  move  and  gen-account  by  the  various 


subjects  in  the  system  can  be  regulated  in  such  a  way  that  it 
is  possible  to  specify  who  can  move  money  between  which 


accounts  and  who  can  generate  new  accounts 


From  the  fact  that  the  procedures  move  and  gen-account  are  the 
only  subjects  which  can  effect  accounts  directly.  We  can  derive  the 
following  conclusion:  The  total  inflow  of  money  into  the  system  minus 
XM.  total  outflow.  Is  equal  to  the  total  amount  of  money  in  the  system 
(the  sum  of  all  non-sink  accounts).  This  "law  of  conservation  of 
money"  can  be  of  enormous  help  for  auditing.  One  knows  that  the  money 
in  the  system  cannot  appear  from  nowhere ,nor  can  it  disappear  into  thin 
air,  and  that  every  generation  or  movement  of  money  is  properly 
documented  in  the  audit  trail  Moreover,  the  auditor  should  be  able  to 
tell  who  can  move  money  from  a  given  account,  and  he  should  be  able  to 
predict  possible  routes  of  money  flow.  For  example,  if  there  is  a 
suspiciously  large  sum  of  money  in  a  given  account,  the  auditor  knows 
at  least  that  this  money  has  been  moved  from  some  other  account  in  the 
system,  and  is  not  due  to  some  wild  update  of  the  record  which 
represents  the  account.  Moreover, the  auditor  should  be  able  to 
identify  the  set  of  subjects  who  might  be  responsible  for  such  a  move, 
even  without  looking  on  the  audit  trail,  [end-of-example] 
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.Aha  tract 


Shis  paper  argues  that  an  authorization  scheme  should,  and  can,  be  based  on 
the  "principle  of  attenuation  of  privileges".  It  is  shown  that  the  well  known 
Access -control  scheme  is  incompatible  with  this  principle,  due  to  its  failure  to 
distinguish  between  "privileges"  and  "abilities".  The  operation-control  scheme. 
Which  is  based  on  the  principle  of  attenuation,  is  described.  The  issue  of 
type-extension  is  discussed  from  the  point  of  view  of  Hydra  and  of  the  proposed 
operation-control  scheme.  The  Implications  of  the  principle  of  attenuation  to 
the  formal  protection  models  introduced  by  Harrison,  Lipton  and  others  are 
briefly  discussed. 
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Introduction 

Authorization  in  computer  system  is  a  discipline  under  which  it  is  possible 
to  Impose  restrictions  on  the  kind  of  action  which  can  be  carried  out  by  the 
various  actors,  usually  called  "subjects" ,  of  a  system.  One  can  distinguish 

between  the  "statics"  and  the  "dynamics"  of  an  authorization  scheme.  By  the 

*• 

terms  statics  we  mean  the  method  used  for  the  representation  of  the  authority  of 
the  various  subjects,  as  well  as  the  technique  for  the  enforcement  of  such 
authority.  What  we  call  the  "dynamics”  of  the  authorization  scheme  is  the 
techniques  used  for  the  manipulation  of  the  "authority-state"  itself. 

.  The  traditional  approach  to  the  design  of  authorization  schemes  seems  to 
start  with  its  statics  and  then  design  a  suitable  dynamics  for  it.  In 
particular,  the  well  known  access-control  AC  scheme  started  from  the  observation 
that  one  needs  in  operating  systems  is  to  specify  for  ecah  subject  which 
operation,  if  any,  he  can  apply  to  each  object  in  the  system.  This  led  to 
Lampson's  access-matrix  model  [Lam  69],  and  to  the  theoretically  equivalent 
"capability-based"  model  [Fab  68].  Studies  of  the  dynamics  of  authorization 
followed  these  developments,  and  have  been  mostly  based  on  the  access-control 
approach  previously  formulated.  These  include  the  work  of  Graham  and  Denning 
[Gra  72],  Jones  [Jon  73],  and  recently  the  more  formal  studies  of  dynamics  by 
Harrison  at. el.  [Har  76],  and  by  Lipton  at. el.  [Lip  77].  These  studies 
revealed  .  some  serious  difficulties  such  as  the  revocation  problem,  the 
undeoidability  of  the  safety  problems,  and,  what  will  concern  us  in  this  paper, 
the  apparent  need  to  perform  amplification  of  privileges.  This  situation 
suggests  to  this  author  that  some  of  the  difficulties  with  the  dynamics  of 
authorization  is  due  to  the  choice  of  statics  on  which  it  is  based. 
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the  approach  of  this  paper  is  to  start  with  some  basic  principles  of  the 
dynaaics  of  authorization,  which  would  lead  us  to  certain  conclusions  about  its 
statics.  More  specifically  we  will  take  the  principle  of  "attenuation  of 
privileges"  as  our  basic  premise.  Informally  speaking,  this  principle  means 
that  privileges  should  not  be  allowed  to  grow  when  they  are  moved  from  one  place 
in 'the  system  to  another.  This  principle  has  been  suggested  by  Denning  [Den  77] 

a 

and  has  been  recently  the  subject  of  some  controversy.  We  believe  that  this 
principle  is  vital  for  our  ability  to  prove  correctness  of  policies,  and  we  will 
show  that  the  access-control  scheme  is  inherently  incompatible  with  it.  The 
wish  to  satisfy  the  principle  of  attenuation  will  lead  us  to  a  new  scheme  called 
operation-control  (OC),  which  has  been  previously  introduced  [Min  77]  for  a 
number  of  different  reasons.  The  operation-control  scheme,  which  is  squarely 
based  on  the  principle  of  attenuation,  can  be  viewed  as  an  extension  of  the 
capability-based  version  of  the  AC  (access-control)  scheme. 

In  the  next  section  the  capability-based  version  of  the  AC  scheme  is 
described.  The  principle  of  attenuation  is  formally  defined,  in  the  context  of 
this  scheme,  and  the  inability  to  satisfy  it  is  demonstrated.  The  underlyir g 
reasons  for  the  incompatibility  of  the  access-control  scheme  with  the  principle 
of  attenuation  is  discussed  in  section  3.  In  section  4,  some  aspects  of  the  OC 
(operation-control)  scheme  are  introduced,  just  enough  to  show  its  compatibility 
with  the  principle  of  attenuation.  A  comparison  between  the  OC  scheme  and  the 
scheme  used  in  Hydra  system  is  made  in  section  5,  and  the  implementation  of 
"type  extension"  under  the  two  scheme  is  discussed  in  section  6. 
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CAP  Scheme 


The  access-control  approach  to  authorization  is  well  documented  in  the 
literature.  In  particular,  the  reader  is  referred  to  the  work  of  Lampson  [Lam 
69, Lam  71],  Graham  and  Denning  [GRA  72],  and  to  recent  review  articles  by 
Seltzer  [Sal  75],  and  Linden  [Lin  76].  Here  we  will  outline  the  main  features 
of  a  class  of  AC  schemes  called  capability-based  [Fab  68,Hul  7^],  using  a 
somewhat  non-standard  terminology  which  is  more  suitable  for  the  rest  of  the 
paper.  He  start  with  the  statics  of  the  capability  based  scheme.  (The  scheme 
to  be  described  above  differs  in  an  assential  why  from  the  scheme  used  in  Hydra. 
Hydra  is  discussed  in  section  5). 


The  objects  to  be  protected  by  the  system  are  classified  into  types.  For 
the  moment  we  will  assume  that  every  object  belongs  to  a  unique  type.  An  object 
of  type  T  will  be  called  a  T-object.  For  every  type  T  there  is  a  fixed  set  of 


operators  (procedures) 


op(T)s{Pi] 


called  T-operators.  It  is  assummed  that  T-operators  are  the  only  subjects  in 
the  system  which  can  directly  manipulate  and  observe  T-objects.  For  all  other 
subjects  the  only  way  to  manipulate  or  observe  T-objects,  is  indirectly  by 
applying  to  them  T-operators.  (He  will  see  later  how  this  rule  can  be  enforced 
by  the  protection  system  itself,  for  all  but  a  fixed  set  of  primitive  types.) 

Also,  for  every  type  T  there  is  a  fixed  set  of  symbols 

rt(TMri) 

called  T-rights .  or  simply  rights.  Objects  of  type  T  (T-objects)  are  addressed 
by  special  kind  of  objects  called  tickets  (*),  which  have  the  form 


(*)  He  are  using  the  term  "ticket"  for  what  is  more  commonly  called  "capability". 
T  reason  for  this  deviation  from  the,  more  or  less,  standard  terminology  will  be 
alarified  later. 
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(b;R) 

Where  £  ia  the  identifier  of  a  T-object  and  £  is  a  subset  of  rt(T).  There  nay 

be  several  tickets  in  the  system  with  the  same  component  b,  they  will  be  called 

b-tlckets .  The  right-symbols  contained  in  a  b-ticket  t  serve  to  determine  which 

T-operators  can  be  applied  (•)  to  b,  when  the  ticket  t  is  used  to  address  it. 
•• 

It *is  in  this  sense  that  a  ticket  represents  privileges  with  respect  to  the 
object  addressed  by  it  For  the  rest  of  this  section  we  assume  the  following  one 
to  one  correspondence  between  T-rights  and  the  T-operators  which  they  authorize: 

The  T-operator  Pi  can  be  applied  to  a  ticket  (b;R)  of  a  T-object 
b,only  if  R  contains  ri. 

In  such  a  case  ri  may  be  called  "the  right  for  Pi".  Although  the  correspondence 
between  rights  and  operators  may  be  more  complex  than  that,  it  is  always 
monotone ,  in  the  following  sense: 

If  an  operator  ff)  can  be  applied  to  a  ticket  t=(b;R) ,  then  it  can  be 
applied  to  any  ticket  t*=(b;R*>  such  that  R'  includes  R. 

This  monotone  property  suggests  the  following  relation  which  defines  a  partial 
order  between  tickets. 

Definition:  A  ticket  ts(b;R)  is  weaker  than  t=(b;R*),  if  R'  includes 

(L  . 


<•>  Since  objects  are  always  addressed  to  by  their  tickets  we  will  frequently  use  the 
phrase  "application  of  an  operator  to  a  ticket",  to  mean  the  application  of  the 
operator  to  the  object  which  is  addressed  by  the  ticket. 

CD  We  frequently  use  the  terms  "operator"  "object"  and  "right",  for  "T-operator", 
■T-object"  and  "T-right"  when  the  identity  of  the  type  T  can  be  understood  from  the 
context,  or  is  not  important. 
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Clearly,  a  weaker  ticket  carries  less  privileges. 

Row,  every  subject  (actor)  in  the  system  is  associated  with  a  special  kind 
of  object  which  we  call  domain  (in  Hydra  [Wul  71*]  it  is  called  the  LNS,  for 
"Local  Address  Space",  of  the  subject).  The  domain  0  of  a  subject  S  contains 

m ■ 

tldkets  of  various  objects  in  the  system,  and  it  is  assummed  that  a  subject  can 
Operate  only  on  tickets  in  his  domain.  In  this  way  the  domain  of  a  subject 
determines  his  authority. 

The  distribution  of  tickets  through  the  system  is  called  the  authority 
state  of  the  system.  The  dynamics  of  the  authority  state  is  discussed  below. 

2.1;0n  the  Dynamics  of  the  AC  Scheme 

Although  there  is  no  general  agreement  as  to  the  ways  in  which  the 
authority  state  of  the  system  is  to  be  changed,  the  dynamics  of  most  AC  scheme 
is  governed  by  the  following  rules.  (Even  if  these  rules  are  not  explicitly 
stated,  or  stated  in  a  different  form.) 

Rule  1:  An  existing  ticket  cannot  be  modified.  ' 

Rule  2:  When  a  T-object  £  is  created,  a  ticket  (b;R)  is  created  with  it, 
with  all  its  possible  rights,  (Namely  Rsrt(T)).  We  will  call  it  the 
primary  b- ticket. 

a 

Rule  3:  There  is  an  operator,  duplicate,  which  when  applied  to  a  b-ticket 
1,  creates  another  b-ticket  in  some  other  place  in  the  system.  T* 
will  be  called  a  direct  derivative  of  t.  (He  will  use  the  term 
"derivative"  of  a  ticket  t  for  a  direct  or  indirect  deri valve  of  t.) 
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To  these,  practically  standard  rules,  we  now  add  another  rule  which  turns 
out  to  be  controversial. 

Rule  b:  The  direct  derivative  of  a  ticket  t  cannot  be  stronger  than  t. 
This  aeans,  In  particular,  that  the  primary  b-ticket  is  the  strongest 
fe-ticket,  for  every  object  b. 

•• 

This  last  rule  is  essentially  what  Denning  [Den  76]  called  the  principle  of 
attenuation  of  privileges.  Although,  as  we  will  see  later,  this  is  an 
enormously  useful  principle,  it  is  violated  by  some  AC  schemes,  notably  by  Hydra 
[Wul  7b,  Cah  75].  One  of  the  main  features  of  Hydra  is  an  operator  amplify 
which  when  applied  to  a  ticket  t,  creates  a  ticket  t*  which  is  stronger  than 
t(*).  Even  Denning  who  was  the  first  to  suggest  explicitly  the  principle  of 
attenuation,  qualifies  himself  by  requiring  it  only  "under  normal  circumstances" 
(Den  76,  p.  372]  (see  also  the  debate  between  Denning  and  Levine  in  the  June  77 
issue  of  Computing  Surveys  [Den  77,  Lev  77]« 

Indeed,  it  turns  out  that  the  principle  &£  attenuation  la  ingpffsatlfrla  with 
-the  AC  scheme.  To  see  this  consider  the  following  example. 

I 

Example  1;  Let  r1,r2  be  T-rights,  for  a  given  type  T,  and  let  P1,P2  be 
I  T-operators  such  that  Pi  can  be  applied  only  to  a  ticket  with  the  right  ri,  for 
1*1,2.  "Now,  consider  the  following  policy  with  respect  to  two  subjects  S1,S2 
and  a  T-object  b. 

j  1)  SI  is  allowed  to  apply  PI  but  not  P2  to  b. 

:  <•)  Actually,  Hydra  allows  only  a  restricted  use  of  the  operator  amplify.  We  will 
'discuss  Hydra  specifically  in  a  later  section. 
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2)  Hith  the  approval  of  S1y  S2  would  be  allowed  to  apply  P2,  but  not 
PI,  to  b. 

I 

He  will  now  see  that  without  amplification  these  simple  requirements  cannot 
be  satisfied  under  a  AC  scheme,  as  it  has  been  described  above. 

m- 

|  •  To  satisfy  requirement  1,  SI  must  be  given  a  ticket  t=(b;r1).  Note  that  t 

cannot  contain  r2  because  this  would  allow  SI  to  apply  P2  to  b.  Now,  how  does 
SI  approve  the  application  of  P2  to  b  by  S2?  The  most  he  can  do  is  to  give  to 
|  S2  a  derivative  t'  of  the  ticket  t  which  he  has  himself.  However,  due  to  the 
principle  of  attenuation  t'  cannot  contain  r2,  which  is  necessary  for  the 
application  of  P2.  Moreover,  S2  himself  cannot  have  a  ticket  for  b  with  r2  in 
)  it  because  this  would  allow  him  to  apply  P2  to  b,  without  the  approval  of  SI. 
Thus,  our  policy  cannot  be  realized. 

^  This  is  the  kind  of  problems  which  prompted . Jones  [Jun  73]  to  introduce  the 

amplification  operator  violating  the  principle  of  attenuation.  In  this  case 
amplification  would  allow  S2  to  add  the  right  r2  to  a  ticket  for  b  given  to  it 
^  be  SI.  Our  approach  to  this  dilemma  is  the  opposite:  taking  the  attenuation  of 
privileges  as  a  fundamental  principle  of  an  authorization  scheme,  we  conclude 
from  this  example  that  the  AC  scheme  itself  is  unsatisfactory  and  should  be 
^  replaced  by  a  scheme  which  is  compatible  with  this  principle.  But  first  we  must 
gain  a  deeper  understanding  of  the  source  of  the  difficulty  demonstrated  above. 

3l  Privileges  versus  abilities 


Authority  structures  such  as  in  example  1 


are  very  common  in  the  real 


(•)  In  the  real  world,  ability  also  depends  on  such  things  as  skill  and  stamina  of 
the  subject,  which  we  have  no  intention  to  model. 
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world,  and  It  would  be  instructive  to  see  how  they  are  handled.  Let  us  consider 


Vauch  real-life  example. 


i 

L 

s 

. 


Example  2:  When  buying  a  car  one  automatically  gets  the  right  to  drive  and  to 
sell  it.  These  rights  can  be  formally  represented  by  a  ticket-like  structure 
(o;drivetsell)  which  stands  for  the  ownership  document  for  the  car  c.  Now, 
consider  a  subject  SI  who  owns  a  car  c,  but  who  does  not  have  a  driving  license. 
This  person  cannot  exercise  his  right  to  drive  his  own  car.  However,  SI  can 
hire  a  driver,  who  does  have  a  driving  license,  authorizing  him  to  drive  the  car 
c  by  giving  him  the  ticket  (c;drive).  No  process  which  even  remotly  resembles 
amplification  is  takink  place  in  this  real-life  situatin.  The  driver  S2  can 
drive  the  car  owned  by  SI  not  because  he  has  more  privileges  for  it,  he  actually 
has  less,  but  because  he  has  another  independent  privilege,  a  driving  license. 


1 

I 

*  . 

.  I 

*  i 

* 

►  - 

* 

i 

►  - 


The  crux  of  the  matter  is  that  in  the  real  world  there  is  a  distinction 
between  the  concept  of  privilege,  or  right,  and  the  concept  of  ability.  The 
ability  to  perform  a  certain  action  may  depend  on  the  availability  of  several 
privileges(*) .  In  this  case:  the  ability  to  drive  a  certain  car  is  formed  by 
the  availability  of  a  driving  license  as  well  as  of  the  right  to  drive  this 
particular  car.  The  problem  with  the  access-control  scheme  is  its  failure  to 
recognize  this  difference  between  privileges  and  abilities.  Under  this  scheme 
the  availability  of  a  b-ticket  with  the  right  rl  in  it  is  sufficient  to  give  a 
subject  the  ability  to  apply  the  operator  PI  to  b.  Thus,  rights  are  being 


<•)  In  the  real  world,  ability  also  depends  on  such  things  as  skill  and  stamina  of 
the  subject,  which  we  have  no  intention  to  model. 


•quoted  with  abilities 


Ve  maintain  that  to  satisfy  the  principle  of  attenuation  of  privileges  one 
must  distinguish  between  privileges  and  abilities.  Such  a  distinction  is  being 
aade  by  the  operation-control  (OC)  scheme  to  be  discussed  next.  The 
protection-scheme  of  the  Hydra  system  [Wul  74]  also  makes  this  distinction,  but 
in  a  less  fundamental,  and  not  quite  satisfactory  way.  The  Hydra  scheme  will  be 
discussed  in  section  5. 

JLi.  The  Operation-Control  LQCI  Scheme 

Under  the  OC  scheme  [Min  77]  the  ability  to  perform  an  operaion 

P(e1,...,ek)  is  formed  by  the  availability  of  two  kinds  of  privileges:  a 

privilege  with  respect  to  the  operator  P,  and  compatible  privileges^)  with 

respect  to  the  objects  e1,...,ek  which  serve  as  the  operands  to  P.  Privileges 

with  respect  to  objects  are  represented  by  means  of  tickets,  just  as  under  the 

AC  scheme.  However,  to  represent  privileges  with'  respect  to  operators  the  OC 

scheme  is  using  a  new  device  called  activator.  In  this  paper  only  a  simplified 

version  of  the  activator  is  described. 

I 

An  activator  is  a  (k+1)  tuple 

<P,c1,...,ck) 

I  where  P  is  an  identifier  of  a  k-ary  operator  and  ci,  for  i=1,...,k,  is  a 
condition  defined  on  the  1-th  operand  of  P.  The  conditions  ci  are  called  the 
operand-patterns  of  the  activator.  The  existance  of  such  activator  in  the 

(*,  The  phrase  "compatible  privileges"  will  be  clarified  later. 
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domain  D(S)  serves  as  a  permission  for  S  to  apply  operator  P  to  a  sequence  of 
objects  q1,...,qk  in  D(S),  which  "match"  the  respective  activation  patterns  (or 
satisfy  the  conditions)  c1,...,ck.  As  a  notational  devise,  we  will  give  a  name, 
say  "A",  to  an  activator  by  writing 

;■  As  <P,c1,...,ck> 

a 

When  an  activator  A  is  used  to  authorize  the  operation  p(q1,...,qk)  we  will  say 
that  the  activator  A  is  applied  to  the  objects  q1,...,qk,  denoting  such  an 
application  by  A(q1,...,qk). 

An  operand-pattern  has  the  form  (•) 

[T;R] 

where  T  is  a  type  and  R  is  a  set  of  T-rights.  This  pattern  matches  (is 
satisfied  by)  any  ticket  (b;R1)  where  b  is  a  T-object  and  R1  includes  R. 

In  order  to  illustrate  the  authorization  role  of  the  activators,  and  their 
relevance  to  our  subject  matter,  we  now  return  to  example  1,  giving  it  the 
interpretation  of  example  2. 


Example  2*:  Let  the  type  T,  of  example  1,  be  CAR.  Let  rt(CAR)s(sell,  drive) 
where  "sell"  is  intended  to  be  the  right  to  sell  a  car,  and  "drive"  is  intended 
to  be  the  right  to  drive  it.  Let  op( CAR) ={ SELL, DRIVE } ,  which  represent  the 
corresponding  actions  on  cars.  Now,  consider  the  subjects  SI  and  S2  whose 
domains  D1,D2  are  described  in  Figure  1.  SI  who  owns  the  car  bl  has  the  ticket 
t1«(b1;sell, drive)  for  it.  However,  he  has  no  DRIVE-activator  in  his  domain. 


f»>  This  is  a  simplified  form  of  the  operand-patterns  introduced  in  [Min  77] 


<P2r  $>ndv*CS2) 


'pf?  thv*uu\(S f) 

{SSlLjJcjfijie/fJ} 
^pitxt/e ,  /uV< J  > 


representing  the  fact  that  SI  does  not  have  a  driving  license.  Thus,  SI  is 
unable  to  drive  bis  own  car  although  he  has  the  "drive"  right  with  respect  to 
it.  This  fact  does  not  make  the  "drive"  right  useless.  It  can  be  used  by  SI  to 
authorize  somebody  else,  S2  in  this  case,  to  drive  his  car.  This  is  done  by 
giving  S2  a  derivative  t1s(b1;drive)  of  his  ticket  tl.  S2  who  has  the 
DRIVE-activator  <DRIVE,[CAR;drive]>,  representing  a  driving  license,  would  now 
be  able  to  drive  the  car  bl.  Thus  the  requirements  of  example  1  are  satisfied, 
without  amplification. 

Rote  also  that  although  both  subjects  have  the  SELL-activator  <SELL, 
[CAR;sell]>,  which  means  that  both  are  allowed  in  principle  to  sell  cars,  the 
driver  S2  is  unable  to  sell  the  car  bl  because  his  bl -ticket  does  not  contain 
the  "sell"  right,  which  is  required  by  his  SELL-activator  [End-of-example]. 

Just  as  there  may  be  several  different  b-tickets  which  are  to  represent 
different  privileges  with  respect  to  a  given  object  b,  we  allow  for  several 
different  P-activators  which  represent  different  privileges  with  respect  to  a 
given  operator  P  (see  example  3).  We  now  introduce  a  partial  order,  between 
motivators. 

Let  A  be  an  activator  of  order  k  (with  k  operand-patterns).  We  define 
ranae(A)  to  be  the  set  of  all  possible  k-tuples  (ql,...,qk)  of  objects,  which 
ean  be  matched  with  the  corresponding  activation-patterns  of  A. 

Let  A  and  A'  be  two  P-activators  for  a  given  operator  P.  We  will  say  that 
A'  is  weaker  than  A  (or,  equivalently,  A  is  stronger  than  A*)  if 
range(A)  includes  range(A').  Such  an  A'  is  also  called  a  reduction  of  A. 


dearly,  the  relation  weaker  between  activators  defines  a  partial  order, 
which  is  analogous  to  the  partial  order  defined  by  the  relation  weaker  between 
tickets. 

Due  to  the  similarities  between  tickets  and  activators  we  will  refer  to 
both  kinds  of  objects  by  the  common  name  "control-objects”,  or  "cobjects”,  for 

a 

short.  Every  cobject  represents  privileges  with  respect  to  the  object  addressed 
by  it,  which  may  be  either  an  operator  (in  the  case  of  an  activator)  or  a 
"passive  object”  (in  the  case  of  a  ticket). 

Mote  that  the  two  types  of  cobjects  play  complementary  roles  in  our  scheme. 
Neither  a  ticket  nor  an  activator  alone  represent  an  ability  to  perform  any 
motion.  Such  an  ability  is  formed  by  the  availability  of  an  activator,  and  one 
or  more  matching  tickets.  To  emphasize  this  complementarity  we  will  use  the 
following  terminology. 

Let  D(S)  be  the  domain  of  a  given  subjee  S.  We  will  use  the  phrase 
"power  of  S”  for  the  set  of  activators  in  D(S),  and  the  phrase  "range 
of  S"  for  the  set  of  tickets  in  D(S). 

Thus,  the  ability  of  a  subject  depends  on  its  range',  which  defines  his  access 
rights  to  various  objects,  as  well  as  on  his  power  which  defines  the  kind  of 
operations  which  he  can  use. 

In.  spite  of  the  (hopefully)  intuitive  appeal  of  these  terms  they  do  not 
Man  much  without  specifying  the  dynamic  behavior  of  the  control  objects.  This 
issue  is  discussed  next. 


i£±L  On  the  dynamics  of  the  operation-control  scheme 
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Here  are  the  rules  which  govern  the  dynamics  of  cobjects,  which  are  a 
generalization  of  the  rules  previously  formulated  for  tickets. 

JUlgJ.:  An  existing  cobjects  cannot  be  modified. 

Rule  2:  Whenever  an  object  o  is  created,  a  cobject  is  created  for  it,  to  be 

r  ealled  the  primary  o-cobject.  (It  would  be  the  primary  b-ticket  if  o 

la  the  passive  object  b,  or  the  primary  P-activator,  if  o  is  the 
operator  P. ) 

Rule  3:  There  is  an  operator  duplicate  which,  when  applied  to  a  cobject  c 

oreates  another  cobject  c*  in  some  other  place  in  the  system,  c'  is 

ealled  a  direct  derivative  of  c.  (By  the  phrase  "derivative  of  c"  we 
mean  direct  or  indirect  derivative  of  c.) 

Rule  The  derivaive  c*  of  a  cobject  c  is  weaker  than  or  identical  to  c. 

Rule  4  is  the  principle  of  attenuation  of  privileges,  now  extended  to 
activators.  An  important  corollary  of  this,  principle  is  that  a  cobject  is 
stronger  than,  or  Identical  to,  every  one  of  its  derivatives.  In  particular, 
the  primary  o-cobject  is  the  strongest  o-cobjct. 

Rote  that  the  above  rules  do  not  define  completely  the  dynamics  of  our 
authorization  scheme.  In  particular,  one  must  define  the  operator  "duplicate" 
and  its  activators,  which  is  done  in  [Min  77].  To  facilitate  the  following 
dlsousslon  we  will  make  the  simplifying  assumption  that  the  set  of  activator  in 
a  given  ’domain  is  fixed.  In  other  words:  the  "power"  of  a  subject  is  assmmed 
to  be  fixed  while  its  range  may  vary.  Although  this  assumption  cannot  be 
strictly  correct  for  all  the  domains  in  a  system,  it  is  likely  to  be  correct  in 
many,  if  not  in  most  cases  (see  [Mln77]).  In  particular,  the  "power"  of  a 
procedure  is  likely  to  be  fixed  while  its  range  varies  from  one  invokation  to 


another 
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On  the  meaning  of  the 


The  aeaning  of  a  given  right  symbol  r  is  best  understood  in  terms  of  the 
affect  that  the  absence  of  r  from  a  ticket  t  has  on  one's  ability  to  apply 
operators  to  the  object  addressed  by  the  ticket.  We  will  see  in  section  that 
su6h  effect  depends  on  the  principle  of  attenuation.  To  facilitate  our 

e 

discussion  we  start  with  an  example. 


Example  3;  Sharing  memoranda 

Let  MEMO  by  a  type  of  objects  which  carry  memoranda  in  an  information 
system.  Let 

op(MEMO)s{READ,  ADD,  DELETE} 
rt(MEM0)={d,r1 ,r2} 

Let  the  following  be  the  primary  activators  of  the  MEMO-operators: 

<READ,  [MEMO]> 

<UPDATE,  [MEMO],  [TEXT]>» 

I 

<DELETE,  [MEMO;d]> 

Note  that  the  rights  rl  and  r2  are  not  used  by  any  of  these  activators. 
The  significance  of  this  will  be  clarified  later. 


(•)  The  second  operand  of  the  operator  UPDATE  should  be  a  TEXT-obJect  which  serves  to 
update  the  memo. 
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Now,  consider  a  group  of  subjects  G={S,S1, S2,S3)  who  are  working  on  the 
same  project  but  have  different  responsibilities  and  authority.  They 
communicate  with  each  other  by  means  of  pool  of  memoranda  whose  tickets  are 
contained  on  a  file  f .  A  ticket  of  a  memo  may  be  stored  in  f  by  members  of  the 
group  G  as  well  as  by  other  subjects  in  the  system.  All  the  subjects  in  G  are 

a 

to  be  allowed  to  read  all  the  uemos  on  f  (namely,  all  the  memos  whose  tickets 
are  stored  on  f).  However,  not  every  subject  is  to  be  allowed  to  update  all 
documents,  or  to  delete  them.  Figure  2  gives  part  of  the  domains  of  the 
subjects  in  G  as  well  as  a  sample  of  the  file  f.  The  description  of  the  domain 
In  Figure  2  is  incomplete  in  the  following  sense.  We  did  not  try  to  account  for 
the  assummed  ability  of  the  four  subjects  in  G  to  read  the  file  f  and  write  into 
it.  The  ability  to  read  f  means  that  every  one  of  the  subjects  in  G  can  get 
MEMO-tickets  from  f  into  his  own  domain.  (This  ability  can  be  formulated  by 
means  of  the  complete  OC  scheme  [Mln77]). 

Now,  note  that  all  the  subjects  of  G  have  a  copy  of  the  primary 
BEAD-activaor  which  enables  them  to  read  all  memos  on  f.  However  they  have 
different  versions  of  the  UPDATE-activator:  The  UPDATE-activator  of  S  does  not 
require  any  rights  in  the  MEMO-ticket  it  is  applied  to.  Thus,  S  can  update  all 
the  memos  on  f.  On  the  other  hand,  the  UPDATE-activator  of  SI  can  be  applied 
only  to  tickets  with  the  right  rl,  which  means  that,  given  the  current  content 
of  f,  SI  can  update  only  the  memos  ml ,m2,m3,mH.  Similarly,  S2  can  update  only 
m2  and  m3*  which  have  the  right  r2.  Finally,  S3  whose  UPDATE  activator  requires 
the  rights  rl  and  r2,  can  update  only  the  memo  m3.  Note  that  m  cannot  be 
updated  by  anybody  in  G. 


Vl~ 
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Also,  only  S  has  a  DELETE  activator,  so  that  he  is  the  only  one  who  can 
delete  memoranda.  Not  all  of  them,  however.  Given  the  content  of  the  file  f 
described  in  Figure  2,  S  can  delete  only  m4  whose  ticket  has  the  d  right. 

Thus,  the  four  subjects  in  group  G  have  different  "power"  with  respect  to 

m- 

the.  MEMO-tickets ,  which  is  formed  by  the  activators  in  their  domains.  Knowing 
about  the  power  of  the  various  subjects  in  G,  the  originator  S'  of  a  memo  can 
oontrol  its  disposition,  as  follows:  Vhen  S'  creates  a  new  memo  m',  he  gets  the 
primary  ticket  t= Cm* ;d,r1 ,r2)  for  it.  If  he  wants  to  allow  every  body  in  group 
G  to  update  m* ,  but  he  does  not  want  them  to  delete  it,  he  would  insert  the 
reduction  (m';r1,r2)  of  t  in  the  file  f.  If  he  wants  only  S  and  SI  to  update 
m'(  then  he  would  insert  (m* ;r1)  into  f,  etc.  [end-of-example]. 

The  main  purpose  of  this  example  is  to  demonstrate  that  a  right-symbol 
might  have  different  meaning  for  different  subjects,  which  allows  our  four 
subjects  to  share  the  same  MEMO-tickets  and  still  have  different  abilities  with 
respect  to  the  memos.  In  order  to  formalize  this  phenomena  we  will  define  the 
concept  of  the  "authority  content",  or  just  "authority"  of  a  right-symbol.  In 
fact,  two  related  concepts  of  authority-  content  will  be  defined. 

PgflnlUpn;  The  absolute  authority  content  of  a  given  right-symbol  r, 
to  be  denoted  by  U(r),  is  the  set  of  operators  whose  primary- 
activators  require  r. 

For  Instance,  in  example  3  U(d)  =  {DELETE}. 

The  significance  of  U(r)  is  due  to  the  principle  of  attenuation:  First, 
because  of  the  attenuation  of  activators,  if  the  primary  P-activator,  for  a 
given  operator  P,  has  a  pattern  which  requires  r,  then  all  P-activators  in  the 
system  would  require  r.  Thus,  the  absence  of  £.  from  &  ticket  £.  inhibits  the 
application  of  P  to  this  ticket.  Moreover,  because  of  the  attenuation  of 
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tickets,  if  t  does  not  contain  r  then  no  derivative  of  t  would  contain  r. 
Therefore,  we  can  sake  the  following  statement: 

The  absance  of  a  right  r  from  a  ticket  t  inhibits  the  application  of 
operators  in  U(r)  to  t  itself  as  well  as  to  all  its  derivatives. 

Foe  example,  consider  a  MEMO-object  m  and  an  m-ticket  t  which  does  not  have  the 
right  d.  (hie  can  put  t  in  the  public  domain  and  remain  confident  that  this 
ticket  cannot  be  used,  neither  directly  or  indirectly,  to  delete  the  object  m. 

Rote  that  by  the  above  definition  the  MEMO-rights  r1,r2  contain  no 
authority.  Indeed,  the  absence  of  rl  from  a  MEMO-ticket  t  cannot  inhibit  the 
applicaion  of  any  MEMO-operato r  to  it.  Yet,  it  is  the  existance  of  rl  which 
allows  SI  to  apply  APPEND  to  a  ticket.  In  order  to  cover  this  phenomena  we  now 
Introduce  the  concept  of  relative  authority  content  of  a  right-symbol. 

Definition:  The  authority  of  a  right  symbol  r,  relative  to  a  domain 
D,  to  be  denoted  by  U(r/D),  is  the  set  of  operators  for  which  there  is 
a  an  activator  in  D  which  requires  r. 

For  example,  U(r1/D1 )={APPEND}  although  U(rl)  is  empty.  The  meaning  of  the 
ooncept  of  relative  authority  is  summarized  by  the  following  statement: 

The  absence  of  r  from  a  ticket  ts(b;R)  in  D=domain(S)  inhibits  S  from 
applying  the  operators  in  the  set  U(r/D)  to  t  and  to  its  derivatives. 
To  understand  the  significance  of  this  statement  note  the  following:  First, 
suppose*  that  P  belongs  to  U(r/D)  but  not  to  U(r).  Let  ts(b;R)  be  a  ticket  in 
Ifcdomain(S)  which  does  not  contain  the  right  r.  It  is  clear  that  S  himself 
oannot  apply  P  to  t.  However,  S  may  be  able  to  cause  the  application  of  P  to 
the  object  b,  by  giving  a  derivative  of  t  to  some  other  domain  D*  such  that  P  is 
not  contained  in  U(r/D'). 
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Secondly,  consider  an  operator  P  which  belongs  to  U(r)  but  not  to  0(r/0) 
(which  can  happen  only  if  D  contains  no  P-activators).  Obviously,  the  absence 
of  r  from  a  ticket  ts(b;R)  in  D=domain(S)  has  no  effect  on  the  ability  of  S  to 
Apply  P  to  object  b  , because  anyway  D  has  no  P-activators.  However,  this 
absence  does  prevent  S  from  causing  the  application  of  P  to  b  by  giving  a 
derivaive  of  t  to  a  subject  which  does  have  a  P-aetivator.  For  example,  suppose 
that  the  domain  D1  of  example  3  contains  the  tickets  t1=(m1;d),  t2~(m2).  Since 
t)(d/D1)  is  empty,  the  right  d  does  not  provide  SI  with  any  direct  ability. 
Indeed,  exactly  the  same  set  of  operators  can  be  applied  by  SI  to  tl  and  t2. 
However,  SI  can  enable  S  to  delete  ml,  by  placing  tl  in  the  file  f,  which  he 
cannot  do  for  m2. 

In  conclusion  note  that  the  OC  scheme  makes  a  much  more  versatile  use  of 
the  right-symbols  than  is  possible  under  the  AC  scheme.  One  of  the  benefits 
which  accrue  from  this  use  is  a  more  economical  utilization  of  tickets.  In 
example  3,  for  instance,  all  the  subjects  in  G  were  able  to  use  the  same 
directory  file.  To  implement  a  similar  authority  structure  under  the  AC  scheme 
one  would  need  four  separate  directory  files,  which  would  result  in  larger 
number  of  tickets  and  additional  complexity  in  their  distribution  (see  also  [Min 
77*Section  4]). 


AnaLiLLgflliaa  la  flydca 

Although  the  authorization  scheme  of  the  Hydra  system  [Wul  74,  coh  75]  is 
usually  considered  to  be  an  access-control  scheme,  it  differs  from  the  AC-scheme 


outlined  in  section  2  in  one  important  way:  Under  Hydra,  the  availability  of  a 
ticket  (capability)  for  an  object  is  not,  by  itself,  sufficient  for  the 
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application  of  an  operator  to  it.  One  oust  also  have  the  permission  to  call  the 
operator.  This  permission  is  represented  by  a  ticket  for  the  operator  with  the 
"call"  right  in  it.  Thus,  in  Hydra  the  ability  to  apply  an  operator  P  to  an 
object  b  is  formed  by  the  availability  of  two  kinds  of  privileges:  a  privilege 
with  respect  to  the  object  b.  and  a  privilege  with  respect  to  the  operator  P. 

a 

However,  Hydra  recognizes  just  one  type  of  privilege  with  respect  to  an 
operator,  an  unqualified  right  to  call  it  which  is  represented  by  a  ticket 
(P;call)  with  the  "call"  right.  This  is  to  be  compared  with  the  varying  degree 
of  privileges  which  can  be  represented  by  our  activators.  This  high  resolution 
Of  privileges  with  respect  to  operators,  apart  of  its  general  usefulness 
demonstrated  by  example  3,  turns  out  to  be  necessary  if  the  authorization  scheme 
is  to  satisfy  the  principle  of  attenuation  of  privileges.  Indeed,  the  designers 
of  Hydra  were  forced  to  violate  this  principle  by  the  introduction  of 
amplification. 

Recognizing  the  harmful  effects  of  amplification  Hydra  restricted  its  use 
to  the  subsystems  which  implement  type-extension  [coh  75].  Unfortunately,  this 
restriction  is  both  too  strict  and  not  sufficient.  More  specifically  we  argue 
that: 

a)  The  restricted  use  of  amplification  in  Hydra 
leaves  a  class  of  policies  unsupported. 

b)  The*  Hydra's  restriction  on  the  use  of 
amplification  does  not  eliminate  all 
its  harmful  effects. 

The  second  claim  will  be  discussed  in  the  next  section  where  we  also  show  that 
under  the  OC  scheme  type-extension  can  be  implemented  without  amplifications. 
To  substantiate  our  first  claim  let  us  return  to  example  2'.  We  will  show  that 
although  the  authority  structure  of  example  2  'can  be  supported  in  Hydra, 


without  amplification,  a  simple  modification  of  it  cannot  be  so  supported. 

The  owner-driver  situation  of  example  2'  can  be  implemented  in  Hydra  simply 
by  representing  a  driving  license  by  a  ticket  (DRIVE;call)  for  the  operator 
DRIVE.  This  ticket  should  be  given  to  the  driver  S2  but  not  to  SI. 

t 

What  makes  this  case  manageable  in  Hydra  is  that  SI  is  not  allowed  to  drive 
any  car.  But  what  about  a  situation  where  SI  is  allowed  to  drive  some  car,  but 
not  his  own?  For  example,  suppose  that  SI  is  a  disabled  person  who  needs  a 
special  permission  to  drive  any  specific  car,  permission  which  may  be  based  on 
the  safety  features  of  that  car. 

The  Hydra  solution  for  example  2'  does  not  work  here  because  both  subjects 
must  have  the  right  to  call  the  operator  DRIVE.  This  shows  that  amplification 
is  necessary  in  Hydra  outside  of  the  modules  which  implement  type-extension. 

Under  the  OC-scheme  this  authority  structure  can  be  represented  as  follows: 
Supposed  that  SI  has  the  following  DRIVE-activator 

<DRIVE,  [ CAR ; drive, sd]> 

which  means  that  SI  can  drive  only  such  a  car  c*  for  which  it  has  a  ticket 
(c';drive,sd...),  "sdN  being  this  special  driving  permission.  If  SI  does  not 
have  the  "sd"  right  for  his  own  car  c  he  cannot  drive  it.  The  driver,  S2,  on 
the  other  hand,  not  being  disabled,  has  the  more  powerful  DRIVE-activator 
<DRIVE,[CAR;d]>  which  can  be  used  to  drive  the  car  c. 

Finally,  it  should  be  pointed  out  that  there  is  a  way  to  simulate  in  Hydra 
the  limited  version  of  the  OC  scheme  described  in  this  paper,  as  follows:  Given 
a  aet  of  P-activators  for  a  given  operator  P,  under  the  OC  scheme,  one 
constructs  in  Hydra  a  set  of  operators  whose  body  is  identical  to  P.  These 
operators  differ  from  each  other  only  in  their  formal-parameter-specifications 
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which  .  must  be  Identical  to  the  operand-patterns  of  the  activators  which  they 
simulate.  The  tickets  (P';call)  for  these  operators  represent  varying  degrees 
of  privileges  with  respect  to  the  original  operator  P,  just  like  our  activators. 
Indeed,  if  this  is  done  systematically  in  a  system  like  Hydra,  no  amplification 
would  be  necessary. 

s 

£l  The  issue  of  type-extension 

In  this  section  we  show  how  type-extension  can  be  achieved  under  the 
OC-scheme,  without  violating  the  principle  of  attenuation.  Moreover,  we  will 
argue  that  the  Hydra  implementation  of  type-extension  has  some  drawbacks  due  to 
the  amplification  on  which  it  is  based.  But  first  let  us  define  the  concept  of 
type-extension.  Definition;  Consider  a  type  T*  such  that  op(T')={Qi)  and 
rt(T')={si}.  Let  T  be  a  type  with  OP(T)={Pi},  T  is  called  an  extension  of  I*  if 
the  following  conditions  are  satisfied:  ' 

1)  Every  T-object  is  also  a  T'-object.  (Note  that  this  violates  the 

assumption  made  in  section  2  that  every  object  belongs  to  a  unique 
type). 

2)  The  only  subjects  which  are  able  to  apply  T’ -operators  to  a  T-object 

are  the  T-operators  Pi.  (Thus,  outside  of  the  T-operators  the  only 
way  to  manipulate  and  observe  T-objects  is  indirectly  by  means  of  the 
T-operators  which  have  the  exclusive  ability  to  "see  the  bare 
*  representation  of  T-objects". 

.  3)  The  set  of  T-rights  is 

rt(T)art(T»)U{ri) 

He  will  refer  to  T'  as  the  representation  type  of  T.  The  set  OP(T’)  are  called 
the  representation  operators.  Note  that  every  T-ticket  may  carry  T*-righvS,  to 
be  called  repres.  Nation-rights,  as  well  as  the  symbols  ri  which  we  call  the 
IntClnglS  T-rlahta. 


In  Hydra  [coh  75],  all  extended  types  are  extensions  of  a  single  primitive 
type  T'sSEGMENT.  The  SEGMENT  operators  in  Hydra  are  called  "generic  operators," 
which  includes  such  operators  as  GETDATA  and  PUTDATA.  The  rights  rt( SEGMENT) 
are  called  "generic  rights".  The  module  which  contains  the  definition  of  OP(T) 
and  rt(T),  for  a  given  type  T,  is  called  the  T-subsystem. 

c 

The  main  difficulty  in  the  implementation  of  type-extension  is  requirement 
(2)  in  the  definition  above.  Here  is  how  the  designers  of  Hydra  see  this 
problem  ([coh  75]  pl47) 

"Hydra  must  somehow  guarantee  that  ordinary  users  cannot  access  or 
manipulate  an  object's  representation. . .This  implies  that  ordinary 
users  do  r&l  haY&  capabilities  I  tickets!  containing  His.  various 
generic  rights... Yet  a  subsystem  procedure  must  be  able  to  gain  these 
rights  when  a  capability  for  an  object  of  the  type  it  supports  is 
passed  to  it  as  an  argument"  (The  underlying  is  mine). 

Hydra's  solution  to  this  dilemma  is  an  exclusive  ability  of  the 
representation-operators  of  a  type  T  to  amplify  T-tickets  (or  capabilities,  in 
Hydra's  terminology)  by  adding  to  them  desired  representation  (generic)  rights. 
We  will  argue  later  that  even  this  restricted  use  of  amplification  is  harmful, 
but  first  we  will  3how  that  uder  the  OC  scheme  amplification  is  not  necessary 
for  type  extension. 


6.1:  The  implementation  of  type-extension  under  the  OC  scheme 

Consider  a  type  T'  which,  like  the  type  SEGMENT  in  Hydra,  serves  as  a 
representation- type  for  a  set  of  extended  types.  Let 
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AQ*<Q,[T* ]> 

be  the  primary  Q-activator  of  one  of  the  T' -operators  Q.  AQ  is  very  powerful  as 
it  can  be  applied  to  any  T* -object,  regardless  of  the  extended  type  it  hosts. 
Ve  assume,  however,  that  for  every  T'-operator  Q  the  primary  Q-activator  exist 
only  in  the  module  which  generates  new  type-subsystems.  Only  reductions  of 

a 

these  activators  are  distributed  among  the  various  type-subsystems,  as  follows: 

Let  T  be  an  extension  of  T'  and  let  P  be  a  T-operator  which  needs  to  ai  ply 
a  representation-operator  Qi  to  its  argument.  Ve  insert  in  the  domain  of  P  the 
following  reduction  of  AQi: 

AQT=<Q,[T]> 

AQT  is  weaker  than  AQ  because  it  can  be  applied  only  to  T-objects.  Namely,  to  a 
T'-obJect  which  hosts  a  T-obJect. 

Now,  since  the  activators  AQT1  exist  only  in  the  domains  of  T-operators, 
only  these  operators  can  apply  T* -operators  to  T-obJects,  as  is  required  by  the 
definition  of  type-extension.  The  dilemma  which  forced  Hydra  to  use 

amplification  does  not  exist  here  since  ordinary  users  do  not  have  any 

representation  activators. 

Of  course,  the  invocation  of  the  T-operators  themselves  is  controlled  by 

their  own  activators.  For  example,  the  primary  P-activator  for  a  T-operator  P 

may  be:  ’ 


where  r  is  one  of  the  T-rights. 
ticket  in  order  to  apply  P 


<P,[T;r]> 

This  means  that  one  needs  the  right  r  in  a 
to  it.  In  general,  the  authority  to  apply 


T-operators  to  a  T-object  can  be  represented  by  the  intrinsic  T-rights  {ri} 
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Note  that  this  suggests  that  there  is  no  need  to  have  the  representation 
rights  (si)  in  T- tickets..  Because,  the  only  way  for  ordinary  users  to  cause  the 
Invocation  of  T' -operators  is  by  Invoking  T-operators,  and  such  invocation  can 
be  controlled  by  the  intrinsic  T-rights.  And  yet,  as  we  will  see  below,  there 
is  a  role  to  be  played  by  the  representation  rights  in  T-tickets. 

6.2:  The  role  of  the  representation-rights 

Consider  a  T-operator  P  whose  primary  activator  is  <P,[T;r]>.  Suppose  that 
P  is  designed  to  use  a  certain  T'-operator  Q  only  on  some  of  its  invocations. 
under  some  special  circumstances,  say.  In  this  case  one  may  want  to  allow  a 
subject  S  to  apply  P  to  a  T-object  b,  but  only  under  the  condition  that  such  an 
application  would  not  cause  the  application  0  to  b.  How  can  that  be 
accomplished?  The  problem  is  that  the  rights  ri  can  only  control  the  ability  of 
a  subject  to  apply  T-operators  to  b,  they  cannot  control  the  internal  operation 
of  the  T-operators  themselves.  Ve  propose  the  following  solution  to  this 
problem. 

Recall  that  previously  we  assumed  that  a  T-operator  P  would  have  in  its 

domain  an  activator  <Q,[T]>  for  every  T'-operator  Q  which  he  might  have  to  use. 

Ve  now  suggest  that  if  an  operator  Q  does  not  have  to  be  used  by  P  on  every 

Invocation,  then  P  should  have  the  following  activator  for  it 
% 

<Q,tT;s]> 

where  s  belongs  to  rt(T').  This  means  that  P  cannot  apply  Q  to  its  argument 
unless  he  has  a  ticket  for  it  with  the  right  s  in  it.  Therefore,  if  the  subject 
S  has  a  ticket  ts(b;r)  he  can  apply  P  to  it,  but  this  application  can  not  resit 
In  the  application  of  Q  to  b  because  t  does  not  contain  s.  If  however,  we  do 


^  •- 
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not  wish  to  prevent  the  application  of  Q  to  b  to  result  from  the  application  of 
P  to  it,  then  we  should  give  S  a  ticket  t'=(b;r,s),  although  the  T’-right  s  is 
not  explicitly  required  by  the  P-activator. 

Thus,  the  T’ -rights  can  be  used  in  the  tickets  of  T-object  as  a  means  to 
control  the  internal  operation  of  T-operators.  The  absence  of  such  a  right  can 
prevent  a  T-operator  from  applying  a  certain  T' -operator  to  its  argument. 

Note  that  this  important  use  of  the  representation-rights  would  be  disabled 
by  amplification.  If  an  operator  P  has  the  ability  to  amplify  its  argument  by 
adding  representation-rights  to  it,  as  is  the  case  in  Hydra,  then  it  does  no 
natter  if  the  operand  ticket  did  not  have  such  a  right  originally. 

It  should  be  pointed  out  that  the  designers  of  Hydra  recognized  this 
problem,  but  only  with  respect  to  certain  representation-operators  (see  [coh  75] 
p152).  Indeed,  their  solution  has  been  effectively,  to  cancel  the  amplification 
for  the  representation-rights  which  control  these  operators.  However,  they 
failed  to  see  the  more  general  nature  of  the  problem  which  requires  the  complete 
elimination  of  amplification. 


Il  Conclusion 

a)  Summery  •  *  « 

b)  Other  aspects  of  the  OC  scheme  0  •  $ 

o)  Implications  of  the  principle  of  attenuation  to  the  formal  protection 
nodelsLntroduced  by  Harrison,  Lipton  and  others 


•  • 
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APglftACT 

A  license  is  a  protection  mechanism  which  is  affiliated 
with  an  access  (algorithm).  It  specifies  by  which  subject 
and  with  what  parameters  the  affiliated  algorithm  may  be 
invoked.  Conceptually,  licenses  are  equivalent  to 
capabilities  and  access  control  lists,  but  many  of  their 
properties  differ.  We  discuss  several  applications  of 
licenses,  including  network  access  control  rnd  flow  control. 
Licenses  may  also  be  used  for  several  of  the  different 
checking  processes  which  are  typical  of  contemporary 
systems.  The  efficiency  of  the  mechanism  is  given  special 
consideration,  and  hardware  features  for  its  support  are 
suggested . 

Key  Words  and  Phrases:  protection,  security,  access 
control,  flow  control,  protected  subsystems,  data  types, 
computer  system  design. 
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The  ultimate  goal  of  current  research  in  protection  and 
security  is  the  certification  of  a  secure  computer  system. 
This  goal  is  approached  on  several  fronts,  including  system 
architectures,  program  certification,  protection  models, 
fault  tolerance,  authentication  methods,  etc.  The  ultimate 
goal  may  not  be  achieved  for  a  while,  but  a  number  of 
research  systems  have  been  successful  with  respect  to 
limited  security  or  in  locating  major  obstacles  to  system 
security  [  And  ,  Neu  ,  Pop  ,  Sa4  ,  Wu1!  ]  .  Since  many  claims  of 
security  have  been  proven  wrong  by  penetration  teams,  it  is 
clear  that  automatic  systems  must  be  employed  to  certify  a 
system  [ De7 , Pop , Wu6 ] .  Several  steps  are  needed  to  prove  a 
complete  implementation  correct.  These  steps  include  the 
choice  of  security  a  jrtions,  their  correspondence  to  the 
design  of  the  protection  system,  the  program  formulation, 
the  compilation,  and  the  hardware  aspects.  We  are 
interested  in  the  design  aspect  of  a  protection  system  and 
how  such  a  system  may  be  supported  by  the  underlying 
architecture  and  mechanisms. 


It  is  presumed  that  the  reader  is  familiar  with  the 
basic  concepts  of  access  control  and  the  refinements  of  the 
standard  protection  mechanisms  [c.f.  Sa5].  For  the 
purposes  of  access  control,  all  information  in  a  system  is 
considered  to  consist  of  disjoint  objects.  Making  use  of  an 
information  object  is  termed  an  access,  and  the  active 
agents  performing  accesses  are  defined  to  be  subjects. 
Accesses  to  objects  occur  after  being  requested  by  a 
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subject,  and  we  shall  use  the  triple  <subject,  object, 
access>  to  denote  such  a  request.  The  task  of  a  protection 
system  is  to  prevent  all  unauthorized  requests  from  being 
performed.  For  this  purpose,  the  protection  system 
maintains  a  data  base  which  specifies  for  each  request 
whether  it  is  authorized  or  not.  Lampson  [Lai]  has  modeled 
this  data  base  as  an  access  matrix  A  such  that  columns  are 
labeled  by  object  names  j  and  rows  are  labeled  by  subject 
names  i.  Element  A[i,j]  of  the  access  matrix  contains  the 
names  of  all  authorized  accesses  which  subject  i  may  perform 
on  object  j.  Since  the  access  matrix  tends  to  be  sparse, 
more  efficient  ways  of  encoding  the  protection  data  base  are 
required.  Two  ways  of  encoding,  namely  those  resulting  from 
compaction  of  rows  and  columns  respectively,  have  attained 
widespread  use.  After  considerable  refinements,  they 
evolved  into  today's  capability  and  access  control  list 
schemes . 

Both  the  capability  and  the  access  control  list  scheme 
have  intrinsic  advantages  and  disadvantages.  In  fact,  they 
appear  to  complement  each  other  in  this  respect. 
Capabilities  have  a  simple  intuitive  interpretation 
("tickets”),  can  be  checked  efficiently,  and  allow 
flexibility  in  their  manipulation  (storing,  copying, 
passing).  They  pose  problems  with  respect  to  revocation, 
propagation,  access  review,  and  accumulation.  Access 
control  lists,  on  the  other  hand,  .are  quite  suitable  for 
auditing,  access  review,  and  revocation.  They  suffer  from 
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limited  efficiency,  allocation  problems,  and  complexity  in 
the  search  during  the  check.  Many  of  the  problems  of  both 
schemes  have  been  alleviated  [Red,SaH],  but  often  at  the 
cost  of  losing  some  of  the  intrinsic  advantages. 
Capabilities  tend  to  excel  when  they  are  exercised  very 
frequently  while  the  opposite  is  true  for  access  control 
lists.  This  property  can  be  exploited  by  using  both  schemes 
in  the  same  system  (e.g.  Multics  [Sa4]),  but  special 
attention  must  be  paid  to  conversion  problems. 


The  access  matrix  can  only  be  compacted  in  two 
dimensions,  but  the  protection  data  base  may  be  represented 
by  two  other  matrices,  the  object  matrix  and  the  subject 
matrix.  Either  one  of  them  is  labeled  by  access  names  along 
one  dimension,  thus  suggesting  a  third  protection  scheme  in 
which  the  protection  data  are  distributed  over  accesses. 
(The  term  algorithm  will  be  used  interchangeably 
henceforth.)  The  basic  datum  affiliated  with  an  algorithm  is 
a  <subject;  object>  pair;  we  refer  to  it  as  a  license. 
The  subject  specifies  an  authorized  requestor,  the  object 
specifies  the  parameter  which  this  requestor  may  use  for  the 
algorithm.  Multiple  parameters  are  acknowledged  by 
replacing  the  term  object  by  the  term  object-list.  Note 
that  this  allows  the  authorization  of  the  composite  request 
COPY(B,A)  without  necessitating  the  authorizations  of  the 
requests  GET ( A )  and  PUT(B)  for  the  same  subject.  Like 
capabilities  and  access  control,  lists,  licenses  offer 


advantages  and  problems.  A  decade  ago,  when  the  only  access 
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attributes  of  interest  were  READ,  WRITE,  and  EXECUTE, 
licenses  would  not  have  had  much  appeal  since  the  degree  of 
distribution  of  the  protection  data  base  would  have  been 
negligible.  However,  with  data  types  playing  an 
increasingly  important  role  and  with  program  verification 
techniques  maturing,  the  license  mechanism  offers  several 
novel  features  for  the  support  of  sophisticated  protection 
systems . 

L 

LICENSES 

A  license  is  a  <subject;  object-list>  pair  affiliated 
with  an  algorithm.  It  authorizes  the  specified  subject  to 
invoke  the  affiliated  algorithm  with  the  specified 
object-list  as  parameters.  At  any  one  instant  in  time,  the 
set  of  licenses  in  the  system  completely  specifies  all 
currently  authorized  operations.  Although  the  licenses 
affiliated  with  a  partic  .  .r  algorithm  could  always  be 
expressed  as  a  set  of  individual  <subject;  object-list> 
pairs,  efficiency  considerations  will  often  dictate  a 
compressed  encoding  of  the  protection  state.  For  instance, 
if  the  object-lists  of  a  large  number  of  licenses  are 
identical,  these  licenses  may  be  replaced  by  a  generalized 
license  with  the  same  object-list,  but  with  an  appropriate 
subject  class  identifier  in  the  subject  field.  The 
compression  of  licenses  is  quite  similar  to  those  techniques 
which  are  used  to  compress  access  control  lists  (c.f. 
[SaU]). 
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From  a  user's  point  of  view,  the  protection  mechanism 
follows  the  conventional  notion  of  licensing.  Two  aspects 
of  licensing  are  crucial.  First,  licenses  must  be  issued  by 
an  appropriate  authority.  Second,  before  the  licensee  (the 
operator)  may  proceed  to  act  upon  a  request,  it  must  be 
checked  that  the  request  is  authorized  by  the  license  issued 
to  the  licensee.  This  check  of  the  request  (the  mediation) 
may  be  performed  by  the  licensee  or  by  some  other  trusted 
agency.  Driver  licenses  and  liquor  licenses  are  typically 
mediated  by  the  licensee,  but  airline  pilot  licenses  are 
also  thoroughly  mediated  by  the  airline  for  which  a  pilot 
flies.  While  a  license  intrinsically  implies  a  right,  it 
also  defines  this  right  quite  narrowly.  A  liquor  license 
implies  the  right  of  selling  liquor,  but  it  also  limits  this 
right  to  certain  types  of  liquor,  certain  ages  of  customers, 
certain  hours  of  the  day  spelled  out  by  state  laws,  etc.. 


As  a  protection  mechanism,  a  license  is  issued 

to 

(affiliated  with) 

an  algorithm  by 

consensus 

of 

the 

controllers  of  all 

quantities 

involved 

in  a  request. 

In 

particular,  the 

consensus 

of  the 

control’ ers 

of 

the 

algorithm,  of  all  objects  in 

the  object 

list.  and 

of 

all 

subjects  listed 

in  the 

license , 

are  required 

• 

The 

verification  of  the 

consensus 

and  the 

attachment 

of 

the 

corresponding  license(s)  to  an  algorithm  is  referred  to  as 
licensing.  Licensing  of  algorithms  is  performed  by  the 
protection  system  which  stores  .  the  new  license(s)  in  the 
license-part  of  the  algorithm. 


A 


Page  7 


When  the  execution  of  an  algorithm  is  requested,  the 
identifier  of  the  requesting  subject  and  the  parameters 
(identifiers  of  all  objects  in  the  object-list  and  parameter 
values)  are  compared  with  the  license-part  of  the  algorithm. 
A  protection  fault  occurs  if  no  match  is  found.  We  delay 
discussion  of  the  format  of  licenses  since  it  depends 
strongly  on  the  type  of  algorithm  with  which  a  license  is 
affiliated.  Algorithms  are  defined  in  terms  of  other 
(lower-level)  algorithms  and  efficiency  considerations 
demand  that  the  complexities  of  an  algorithm  and  the 
corresponding  mediation  mechanism  are  somewhat  related.  In 
particular,  the  overhead  involved  in  mediation  should  be 
small  compared  to  the  execution  of  the  algorithm.  Thus, 
licenses  of  hardware  algorithms  will  often  consist  of  only  a 
few  bits,  while  the  licenses  affiliated  with  a  complex 
procedure  may  well  occupy  an  entire  secondary  storage  block. 

THE  TECHNOLOGICAL  HIERARCHY  0£  ALGORITHMS 

Algorithms  are  static  descriptions  of  clerical 
procedures  which  may  be  invoked  for  execution  or 
interpretation.  We  shall  refer  to  the  interpretation  of  an 
algorithm  as  an  operation.  The  form  of  the  static 
description  depends  on  the  complexity  of  the  algorithm  and 
may  be  implemented  in  hardware  or  software.  An  algorithm 
for  a  register-register  transfer  will  often  be  implemented 
as  a  micro  instruction;  the  static  description  is  then 


provided  by  a  specific  gate  configuration.  Conversely,  the 
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algorithm  for  a  compilation  is  typically  represented  by  a 
procedure,  a  sequence  of  machine  instructions.  In  general, 
we  may  conceive  of  algorithmic  descriptions  as  a  partial 
ordering  with  the  relation  "is  a  sequence  of”.  This  partial 
ordering  defines  an  algorithmic  hierarchy:  commands, 
procedures,  machine  instructions,  [micro  instructions,  [nano 
instructions,]]  logic  control  lines.  Applying  the  concept 
of  levels  of  abstractions  [Dij],  procedures  may  further  be 
subdivided  into  different  levels  of  procedures.  (We  defer 
for  the  time  being  the  case  of  a  procedure  calling  another 
one  of  the  same  level.)  Note  that  every  algorithm  in  the 
system  is  uniquely  identified  by  a  level  number  and  an 
algorithm  number  of  that  level.  (The  algorithm  number  of  a 
machine  instruction  is  simply  the  operation  code.)  The 
algorithmic  hierarchy  is  depicted  in  Figure  1.  Other 
aspects  of  this  figure  will  be  discussed  below. 

An  operation,  i.e.  an  interpretation  of  an  algorithm, 
proceeds  according  to  the  static  description  of  that 
algorithm.  Every  system  provides  the  necessary  controls  for 
fetching  the  algorithm  number  and  the  parameters  of  the 
algorithm  to  be  invoked  next,  and  for  executing  it.  A 
different  interpreter  (level  interpreter)  is  provided  for 
this  purpose  on  each  level  of  the  hierarchy.  In  particular, 
control  lines  are  interpreted  by  gates,  nano  instructions  by 
the  nano  control  unit,  micro  instructions  by  the  micro 
control  unit,  machine  instructions  by  the  control  unit,  and 
commands  by  the  command  level  interpreter  (command 
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processor).  Portions  of  the  operating  system,  like  the 
scheduler,  the  interrupt  system,  and  the  CALL,  interpret 
procedures  on  the  various  levels.  Note  that  each  level 
interpreter  is  itself  a  sequence  of  lower  level  algorithms. 
For  example,  the  command  level  interpreter  is  a  sequence  of 
procedures  and  the  control  unit  (unless  it  is  hard-wired)  is 
implemented  as  a  sequence  of  micro  instructions. 

The  protection  mechanism  for  mediating  an  operation  is 
closely  related  to  its  corresponding  level  interpreter.  The 
level  interpreter  of  any  level  loops  over  the  two  phases 

fetch;  execute; 

thus  controlling  the  sequence  of  consecutive  operations. 
Mediation  may  be  performed  between  these  two  phases: 

fetch;  mediate;  execute; 

Mediation  involves  a  comparison  of  the  identifier  of  the 
currently  active  subject  and  the  parameters  (object-list) 
with  the  license(s)  affiliated  with  the  algorithm.  The 
overhead  is  a  function  of  both  the  type  of  comparison 
(simple  match,  associative  search)  and  the  access  time  of 
the  storage  in  which  the  licenses  reside.  For  a  command,  an 
associative  search  of  licenses  residing  on  secondary  storage 
is  satisfactory  since  most  likely  the  command  itself  must  be 
paged  in.  For  a  machine  instruction,  however,  all 
quantities  involved  in  the  mediation  must  be  in  high  speed 
storage  or  at  least  in  primary  memory.  In  the  next  section 
we  shall  discuss  various  encodings  of  licenses  on  different 


levels  as  well  as  their  lifetimes 
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The  implication  of  a  verified  algorithm  on  the  form  of 
level  interpreters  deserves  some  attention.  The  current 
state  of  the  art  allows  the  verification  of  short 
procedures,  but  fails  with  respect  to  complex  software.  On 
the  other  hand,  hardware  algorithms  can  readily  be  verified 
by  standard  testing  techniques.  Thus,  the  form  of  a 
hardware  level  interpreter 

fetch;  mediate;  execute; 
is  typically  replaced  by 

fetch;  mediate  while  executing; 

This  form  is  more  efficient  since  the  mediation  does  not 
have  to  apply  to  all  algorithms  of  the  particular  level,  but 
may  be  specialized  for  one  or  more  algorithms.  Privileged 
instructions  in  which  the  mode  is  checked  during  the 
execution  of  the  instruction  represent  a  trivial  example  of 
this  specialization.  The  Multics  access  checking  logic  for 
the  implementation  of  rings  in  hardware  represents  a  more 
involved  example  [Sh2].  Similarly,  procedures  of  low  levels 
of  abstraction  which  tend  to  be  more  easily  verified,  may  be 
trusted  to  perform  their  own  mediation.  On  a  higher  level, 
both  forms  may  coexist  by  slightly  modifying  the 
corresponding  level  interpreters: 

fetch;  if  verified  mediate  while  executing 
else  mediate  before  executing; 


For  efficiency  reasons  the  protection  checking 
mechanism  in  capability  systems  is  tightly  coupled  with  the 
addressing  mechanism  [Sa5].  Quite  analogously,  the  license 


mechanisms  for  mediating  requests  are  closely  coupled  with 


level  interpreters.  It  follows  that  these  mechanisms  are 
distributed  over  the  algorithmic  hierarchy  and  can  be 
designed  to  minimize  the  cost/performance  characteristics  of 
the  protection  system.  Furthermore,  while  efficiency 
considerations  are  used  in  the  design  of  the  mechanism  of  a 
particular  level,  the  conceptual  framework  applies  to  all 
levels  independent  of  their  technological  characteristics. 
Note  that  the  same  mechanisms  are  used  for  access  control 
and  parameter  checking;  the  latter  aspect  has  proven 
particularly  troublesome  in  attempting  to  verify 
commercially  available  systems.  In  all  protection  systems 
the  CALL  governing  transitions  between  procedures  plays  an 
important  role.  The  notion  of  level  interpreters 
generalizes  this  primitive  for  all  types  of  algorithms. 

THE  HIERARCHY  £F  LICENSES 

In  a  pure  licensing  scheme,  the  protection  state,  i.e. 
the  collection  of  triples  encoding  authorized  operations,  is 
distributed  over  the  algorithmic  repertoire  of  the  system. 
Dynamic  mediation  is  performed  when  an  operation  is  invoked 
by  a  level  interpreter.  In  order  to  keep  the  overhead 
tolerable,  the  access  times  of  all  quantities  involved  in 
the  mediation  must  be  comparable  to  the  fetch  time  of  the 
algorithmic  specification.  When  a  procedure  must  be  fetched 
from  secondary  storage,  it  is  sufficient  to  have  its 
licenses  resident  on  secondary  storage.  On  the  other  hand, 


the  licenses  of  a  machine  instruction  must  be  readily 
accessible  in  high  speed  storage.  Consequently  the 
protection  state  itself  is  distributed  over  a  hierarchy  of 
storage  media  which  is  related  to  the  algorithmic  hierarchy. 
Figure  1  illustrates.  We  refer  to  the  licenses  of  one 
algorithmic  level  as  the  (protection)  data  base  of  that 
level.  Conceptually,  the  data  base  of  a  level  is  organized 
around  the  algorithms  of  that  level,  i.e.  <subject; 
object-list>  pairs  are  grouped  and  affiliated  with  their 
respective  algorithms.  In  an  implementation,  algorithms  of 
the  same  level  may  often  have  identical  licenses  affiliated 
and  duplication  of  the  contents  of  their  license-parts  may 
be  avoided  by  merging  them. 

Some  of  the  existing  hardware  protection  features  may 
be  viewed  in  this  light.  The  processor  state  bit  is  an 
example  of  a  (rudimentary)  subject  class  identifier  used  on 
the  machine  instruction  level.  Here  all  subjects  are 
divided  into  two  groups  (user  and  system).  Let  us  also 
assume  for  the  moment  that  the  object-list  field  in  all 
licenses  will  match  any  parameters.  Thus,  the  set  of  all 
possible  licenses  reduces  to  the  following  three:  <user; 
ALL>,  <system;  ALL>,  Cuser  or  system;  ALL>.  Accordingly, 
all  machine  instructions  may  be  partitioned  into  three 
groups  each  of  which  shares  an  identical  license.  In  a 
hardwired  control  unit  these  licenses  are  wired  into  the 
instructions  and  mediation  involves  a  simple  comparison  with 
the  processor  state  bit.  n-state  architectures  with  n >2, 
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like  ring  structures,  allow  for  further  discrimination  among 
subjects . 

A  standard  paging  map  as  depicted  in  Figure  2  may  be 
considered  part  of  a  micro  instruction  data  base.  It 
contains  the  licenses  for  the  micro  instructions  read, 
write,  execute  (i.e.  read  during  the  fetch  phase  of  the 
machine  instruction  interpreter),  and  map.  Objects  are 

identified  by  virtual  page  numbers.  The  license  of  read, 

t 

for  example,  is  of  the  form  CALL;  any  virtual  page  number 
with  R-bit  set>.  The  column  of  invalid  bits  forms  the 

license  of  the  micro  instruction  map  which  performs  the 

mapping  of  virtual  into  physical  page  numbers.  In  tnese 
examples  of  existing  hardware  protection  features  the 
object-list  fields  in  machine  instruction  licenses  are 

degenerate  and  so  are  the  subject  fields  of  the  licenses  of 
the  four  micro  instructions.  Degenerate  licenses  are  more 

I 

efficient  in  the  mediation  process,  but  more  complex  formats  | 

are  justified  in  the  case  of  more  complex  algorithms  like 
operating  system  support  instructions. 

The  hardware  examples  served  to  demonstrate  the 
necessity  of  updating  protection  data  bases  at  lower  levels 
dynamically  in  order  to  keep  the  cost  (in  terms  of  both 
complexity  and  storage)  of  the  mediation  process  reasonable. 

We  generalize  this  notion  to  all  levels.  Upon  successful 
mediation  of  an  operation  on  one  level,  licenses  are 


converted  and  added  to  the  data  base  of  the  next  lower 
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level.  (In  implementations,  depending  on  the  nature  of  a 
particular  system,  a  higher  level  interpreter  may  cause  the 
data  bases  of  several  lower  levels  to  be  updated  with 
licenses.)  In  essence,  the  new  licenses  on  the  lower  level 
are  derived  from  the  licenses  involved  in  the  mediation 
process.  The  newly  created  licenses  on  the  lower  level 
reside  there  until  the  operation  responsible  for  their 
creation  terminates.  This  scheme  is  motivated  primarily  by 
the  desire  to  avoid  the  longevity  problem  of  capabilities 
with  all  its  consequences  while  retaining  most  of  their 
efficiency  characteristics. 

Procedures  and  commands  differ  form  lower  level 
algorithms  in  that  they  may  be  defined  in  terms  of 
algorithms  of  the  same  level.  This  does  not  change  the 
basic  scheme  for  creating  and  deleting  licenses  at  the 
procedure  levels.  Similarly  to  the  CALL  stack  employed  in 
contemporary  operating  systems  for  control  purposes,  a  stack 
is  used  to  link  the  saved  licenses  of  the  data  bases  of 
procedures  and  lower  levels  when  control  passes  from  one 
procedure  to  another  of  the  same  level.  Upon  RETURN  from  a 
procedure,  the  licenses  in  the  top  element  of  the  stack  are 
deleted.  It  is  instructive  to  compare  this  method  with  the 
handling  of  templates  in  HYDRA  [Coh].  Before  a  procedure 
may  be  invoked,  the  triple  <calling  subject;  procedure; 
parameters)  must  be  mediated.  In  HYDRA,  the  mediation  is 
split  into  two  indepedent  steps.  First,  the  calling  subject 
must  present  a  capability  for  executing  the  procedure. 
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Second,  the  parameters  (the  passed  capabilities)  arc 
compared  with  the  templates  which  are  affiliated  with  the 
procedure.  A  positive  outcome  results  in  the  creation  of 
new  capabilities  for  the  lifetime  of  the  procedure.  Like 
templates,  licenses  are  affiliated  with  procedure.  The 
mediation,  however,  is  performed  in  one  step  by  comparing 
the  licenses  with  the  identifier  of  the  calling  subject  in 
the  context  of  the  passed  parameters. 

t 

ON  THE  ENCODING  OF  LICENSES 

Contemporary  hardware  architectures  offer  only  minimal 
support  for  protection  systems.  This  support  includes 
processor  modes,  memory  maps,  and  descriptor  mechanisms. 
However,  even  tag  bits  for  capabilities  or  capability 
registers  are  rare  (c.f.  [Eng]  as  an  example).  In  fact, 
most  commercially  available  processors  lack  the  necessary 
features  to  aid  in  the  implementation  of  a  secure  system 
[Smi],  The  increase  in  cost-effectiveness  of  hardware 
features  and  microcode  over  software  in  the  past  few  years 
has  resulted  in  the  enhancement  of  hardware  architectures 
with  operating  system  support  features  (e.g.  virtual  memory 
mechanisms,  special  purpose  instructions).  A  similar  trend 
is  to  be  expected  for  protection  features.  In  particular, 
we  suggest  a  feature  which  would  allow  the  labeling  of 
information  containers  (page  frames,  register  sets,  tapes) 
in  a  uniform  manner  across  an  entire  system,  including 
periphery.  Any  physical  storage  unit  should  feature  a 
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string  of  bits  describing  its  current  contents.  For  a 
primary  memory  page  this  string  would  be  stored  in  an 
affiliated  register.  On  secondary  storage  this  string  would 
precede  (and/or  accompany  and/or  trail)  the  corresponding 
information  block.  These  strings  would  aid  in  the  design  of 
memory  management  systems  which  are  so  closely  related  to 
protection  systems  that  they  are  often  included  in  the 
system  kernel.  The  contents  of  these  strings  is  twofold:  a 
unique  identifier  of  the  virtual  object  contained  in  the 
physical  storage  unit  and  a  semantic  description  of  its 
contents  (e.g.  security  class,  type). 

The  unique  identifiers  for  algorithms  are  given  by  a 
level  number  and  a  unique  algorithm  number.  For  procedures, 
the  latter  is  the  procedure  segment  number  which  corresponds 
to  a  pathname  in  the  procedure  directory  stai ting  with  the 
name  of  the  controlling  user.  Operations  (invoked 
algorithms)  are  identified  by  the  algorithmic  path  name, 
i.e.  the  sequence  of  algorithms  which  define  their  current 
context.  Thus,  a  machine  instruction  in  execution  is 
identified  by  the  sequence:  command  identifier  -  procedure 
identi f ier ( s )  -  operation  code.  Subjects  are  uniquely 
identified  by  the  name  of  the  invoking  user  concatenated 
with  the  current  operation  identifier.  Note  that  part  of 
the  subject  identifier  changes  with  every  instruction. 
Semantic  information  about  a  subject  includes  a  security 
class  and  a  privilege  class  The  mapping  between  virtual 
and  physical  objects  is  maintained  by  the  T.-mory  management 
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system.  The  contents  of  any  physical  location  is  always 
part  of  a  virtual  object  (segment).  The  mapping  of  bits, 
words,  pages,  and  segments  defines  an  object  hierarchy  which 
is  utilized  in  the  conversion  of  licenses  when  they  are 
added  to  the  data  base  of  the  next  lower  level.  Segments 
are  identified  by  segment  numbers;  they  correspond  to 
pathnames  in  the  object  directory  starting  with  the  name  of 
the  controlling  user.  Semantic  information  about  an  object 
includes  a  type  and  a  security  level. 

The  design  of  a  protection  system  based  on  licenses 
depends  on  the  concrete  specific.'. tions  of  the  formats  of 
identifiers  (including  semantic  information).  These 
specifications,  in  turn,  depend  as  much  on  the  hardware 
architecture  as  they  depend  on  the  specific  operating  system 
structures.  We  have  simulated  both  a  hardware  configuration 
and  an  operating  system  to  investigate  the  properties  of 
licenses.  Due  to  its  specific  nature,  our  design  is  beyond 
the  scope  of  this  paper  and  we  refer  the  reader  to  [Shi]  for 
details.  A  general  comment  about  our  effort  is  in  order 
though.  The  set  of  licenses  affiliated  with  an  algorithm  is 
conceptually  a  list  and  there  are  many  analogies  to  access 
control  lists  as  far  as  compression  techniques  are  concerned 
[c.f.  SaM].  What  distinguishes  a  license  from  an  access 
control  list  entry  is  the  fact  that  mediation  involves  a 
context-sensitive  comparison  of  a  subject  identifier 
consisting  of  many  subfields  with  several  parameters 
(especially  object  identifiers  with  again  many  subfields). 
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The  subfields  help  since  often  only  one  of  them  has  to  be 
consulted  to  make  a  decision.  The  context-sensitive  nature 
results  in  the  notion  of  identifier  variables  in  the 
licenses.  Consider  the  case  of  a  procedure  which  the 
controller  would  like  to  make  available  to  all  users  under 
the  condition  that  they  may  pass  only  objects  under  their 
own  control.  Assigning  the  variable  x  to  denote  any  user 
name,  the  compressed  license  can  be  represented  as  <x; 
x.ALL,  x.ALL,  ...  x.ALL>.  If  x  denotes  the  name  of  the 
controlling  user,  the  above  license  specifies  a  no-sharing 
situation  and  illustrates  the  economy  of  the  scheme  for 
simple  policies. 

The  components  of  a  license  do  not  only  contain 
identifiers,  but  also  semantic  information  about  the 
involved  objects  and  subjects.  When  the  mediation  process 
can  be  based  on  the  semantic  information  alone,  it  is 
usually  considerably  more  effective.  In  the  next  two 
sections  we  discuss  several  applications  for  which  the 
license  scheme  seems  to  be  particularly  suited. 

DATA  TYPES .  PROTECTED  SUBSYSTEMS  AND  NETWORKS 

A  data  type  defines  a  class  of  objects  by  specifying 
its  internal  data  representation  and  the  externally 
invocable  access  procedures.  It  is  a  predominant  feature  of 
data  types  that  the  internal  data  may  only  be  accessed  via 
the  specified  access  procedures.  The  notion  of  data  types 

evolved  in  a  number  of  programming  languages,  like  Simula  -> 

\ 
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[Dah],  CLU  [Lis],  and  Alphard  [Wu6],  to  support  the 
discipline  of  structured  programming.  It  has  since  become 
an  important  operating  systems  notion  too  [c.f.  Coh].  Data 
types  may  be  created  by  a  user  by  obtaining  a  unique  type 
identifier  from  the  system.  In  doing  so,  this  user  becomes 
the  controller  of  the  new  type.  After  the  appropriate 
access  procedures  have  been  coded,  they  are  licensed  such 
that  a  passed  parameter  specifying  the  new  data  type  must  be 
of  that  type.  The  subject  fields  in  the  licenses  of  the 
access  procedures  need  not  be  identical,  thus  allowing  for 
discrimination  among  subjects  with  respect  to  different 
accesses  to  the  same  type.  No  further  steps  are  required. 
Other  users  may  make  use  of  the  new  type  if  they  have  been 
included  in  the  licenses  of  the  access  procedures. 
Otherwise,  they  may  create  data  objects  of  the  new  type,  but 
cannot  access  them  themselves.  An  attempt  to  circumvent 
this  restriction  by  coding  new  access  procedures  would  fail 
at  the  time  of  licensing  since  the  consensus  of  the 
controller  of  the  new  type  is  required.  (This  consensus  may 
be  given  under  special  circumstances,  e.g.  when  a  type 
controllership  is  passed  from  one  user  to  another.)  The 
internal  data  representation  of  a  new  type  must  be  defined 
in  terms  of  existing  types  and  the  descriptor  to  a  data 
object  of  this  type  maps  its  name  into  a  set  of  descriptors 
of  objects  of  the  defining  types.  Note  that  the  access 
procedures  of  the  new  type  must  be  coded  in  terms  of 
accesses  to  the  defining  types,'  thus  necessitating  the 
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consensus  of  their  controllers.  A  data  type  is  a  unique 
abstract  description  according  to  which  an  arbitrary  number 
of  concrete  objects  may  be  created.  Related  to  this  concept 
is  the  concept  of  a  protected  subsystem  of  which  only  one 
instance  may  be  created. 

A  protected  subsystem  is  a  collection  of  procedures  and 
data  objects  that  is  encapsulated  in  such  a  way  that  the 
data  objects  may  be  accessed  only  by  the  procedures  of  the 
protected  subsystem.  Protected  subsystems  are  instrumental 
in  the  implementation  of  sophisticated  security  policies. 
Many  cases  of  such  policies  have  been  discussed  in  the 
literature,  in  particular  the  handling  of  mutual  suspicion 
[ShD,  Sa5],  confinement  [La9i  Sa5],  and  user-defined  access 
control  like  access  to  student  grade  records  [Gra,  Sa5]. 

The  basic  license  mechanism  supports  the  implementation 
of  protected  subsystems.  Since  all  procedures  have 
license-parts  which  specify  the  subjects  that  may  invoke  the 
procedure  with  certain  parameters  (including  objects),  any 
procedure  is  potentially  part  of  a  protected  subsystem. 
Suppose  data  objects  D  and  E  are  to  be  encapsulated  with 
procedures  P  and  Q.  At  the  time  of  creation  of  P  and  Q  they 
are  licensed  to  access  D  and  E  (i.e.  <S;  D,  E>  pairs  are 
affiliated  with  them  where  S  specifies  the  authorized 
callers).  As  long  as  no  other  procedure  is  ever  given  a 
license  including  D  or  E,  the  two  procedures  and  the  two 
data  objects  form  a  subsystem. 
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Figure  3  illustrates  an  example  concerning  the  policy 
that  physicians  (PHYS)  should  have  complete  access  to 
patients'  records  while  statisticians  (STAT)  should  be 
constrained  by  privacy  considerations.  We  assume  first  that 
patients'  records  are  kept  in  two  separate  data  objects, 
with  the  personal  data  stored  in  object  PERS  and  the  medical 
ones  in  object  MED.  The  procedure  PPHYS  is  coded  to  service 
all  physicians'  accesses  and  is  licensed  with  <PHYS;  PERS, 
MED> .  Similarly,  the  procedure  PSTAT  serves  statisticians 
and  is  licensed  with  <STAT;  MED> .  Note  that  the  licenses 
do  not  only  determine  which  data  objects  may  be  accessed, 
but  also  which  subjects  may  invoke  the  particular  procedure. 
Of  course,  the  data  objects  PERS  and  MED  could  be  merged 
into  a  single  object.  In  this  case,  the  procedure  PSTAT 
would  have  to  be  verified  to  ensure  that  no  personal  data 
are  returned  to  statisticians.  If  statisticians  were 
allowed  to  obtain  averages  of  personal  data,  but  not  the 
personal  data  themselves,  verification  is  unavoidable  since 
this  case  subsumes  the  general  case  of  data  transformations. 

The  operating  systems  of  most  computer  systems  may  be 
viewed  as  protected  subsystems.  User  programs  rely  on 
accesses  to  system-maintained  data,  but  these  accesses  must 
be  performed  via  (more  or  less)  verified  system  procedures. 
Conceptually,  the  notion  of  a  protected  subsystem  may  be 
further  extended  to  computer  networks.  Figure  4  shows  a 
network  configuration  with  several  hosts.  A  message 
arriving  at  a  host  represents  a  request  for  a  specific 


Fig. 3.  A  protected  subsystem  for  a  privacy  policy 
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operation  on  that  host.  We  extend  the  hierarchy  of  level 
interpreters  to  include  a  host  level  interpreter  and  an 
affiliated  mediation  mechanism.  This  mechanism  mediates  by 
matching  the  relevant  message  portions  (source  subject, 
requested  operation,  and  parameters)  with  the  licenses  in 
the  host  protection  data  base.  Of  these  relevant  message 
portions  only  the  identifier  of  the  source  subject  must  be 
unforgeable.  The  integrity  of  this  identifier  can  be 
assured  by  a  simple  and  efficient  scheme  based  on  Lampson's 
model  of  the  Message  System  [Lai],  Modifications  of  other 
portions  of  the  message  en  route  does  not  jeopardize  the 
security  of  the  license  mechanism;  in  the  worst  case,  it 
would  result  in  an  unnecessary,  but  still  authorized, 
operation . 


FLOW  CONTROL 

Access  control  mechanisms  are  designed  to  support  the 
dynamic  mediation  of  requests  concerning  the  accesses  of 
objects  by  subjects.  Authorized  requests  are  denoted  in  the 
protection  data  base.  To  a  large  degree,  the  encoding  of 
this  data  base  determines  the  nature  of  the  access  control 
mechanism.  In  the  capability  scheme,  the  access  control 
list  scheme,  and  the  license  scheme,  the  protection  data 
base  is  organized  along  subjects,  objects,  and  algorithms 
respectively.  Owing  to  the  distributed  nature  of  the  data 
base  in  all  three  schemes,  it  is  often  difficult  to  account 
for  all  possible  data  movements  (with  possible 
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transformations  on  the  way)  in  a  global  sense.  Flow  control 
concerns  itself  with  this  problem.  A  secure  system  must 
provide  mechanisms  to  support  the  control  of  both  accesses 
and  information  flow. 

An  appealingly  simple  model  for  flow  control  [De6]  has 
resulted  in  a  certification  mechanism  for  verifying 
information  flow  through  a  program  [De7].  In  this  model, 
objects  (and  processes)  are  bound  to  disjoint  security 
classes  which  serve  to  define  authorized  information  flow. 
Briefly,  the  result  of  a  procedure  which  takes  data  from 
several  input  objects  may  only  be  stored  in  an  output  object 
of  a  given  security  class  if  information  may  flow  from  all 
security  classes  to  which  any  input  object  is  bound  to  the 
security  class  of  the  output  object.  Note  that  authorized 
flow  is  defined  independent  of  the  particular  procedure 
which  controls  the  transformation  of  the  flowing 
information.  This  property  simplifies  the  necessary 
mechanism.  It  also  implies  that  the  security  class  of 
derived  information  must  not  be  less  than  the  security 
classes  of  information  used  in  the  derivation.  On  the  other 
hand,  a  procedure-dependent  mechanism  would  increase  the 


versatility 

of  the 

model 

.  In  particular, 

it  would  be 

possible  to 

decrease 
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medical  data 

themselves.  Similarly,  the  output  of  an  encyphcring 
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procedure  is  intrinsically  less  sensitive  than  its  input. 

For  access  control,  the  object-list  field  of  a  license 
already  contains  an  encoding  (including  type  and  security 
class)  of  all  authorized  input  and  output  objects.  Thus,  if 
the  security  class  of  the  output  object  passed  by  the  caller 
does  not  match  the  security  classes  of  the  input  objects,  a 
protection  fault  will  result.  (The  same  holds  true  for  the 
case  of  several  output  objects.)  Thus,  the  license  mechanism 
requires  no  changes  in  order  to  implement 
procedure-dependent  flow  control.  The  valid  range  of 
security  classes  of  output  objects  is  statically  determined 
at  the  time  of  licensing.  To  implement  dynamic  binding  of 
objects  to  security  classes,  we  add  to  the  license-part  of  a 
procedure  a  description  of  the  mapping  of  the  security 
classes  of  the  input  objects  to  those  of  the  output  objects. 
Furthermore,  the  mediation  mechanism  affiliated  with  the 
procedure  level  interpreter  is  enhanced  to  evaluate  this 
mapping  and  to  update  the  security  classes  of  the  output 
objects.  By  default,  all  procedures  would  have  the  standard 
least  upper  bound  mapping  assigned  and  the  consensus  of  the 
protection  system  is  required  to  specify  a  decreasing 
security  mapping. 

Licenses  derive  many  of  their  characteristics  from  the 
fact  that  object  identifiers  and  the  affiliated  semantic 
information  are  viewed  like  parameters.  This  property 


allows  context-sensitive  access  control  with  respect  to 


object  combinations,  in  particular  combinations  of  input  and 


output  objects.  The  same  property  aids  in  the 
implementation  of  flow  control.  Thus,  licenses  appear  to  be 
a  suitable  mechanism  for  the  implementation  of  both  access 
and  flow  control. 

SIMULATION  ASPECTS 

We  have  designed  and  simulated  an  integrated  hardware 
and  operating  system  configuration  to  investigate  the 
properties  of  a  protection  system  based  on  licenses.  Our 
design  is  strongly  influenced  by  an  educational  system  which 
is  being  simulated  as  part  of  a  course  in  operating  systems 
[RuA],  In  this  course,  special  emphasis  is  put  on  the 
interactions  between  hardware  and  software,  and  the  major 
components  of  the  system  -  the  machine  architecture  (COS 
[Ru1,Ru2]),  the  implementation  language  (CAL  [RuL]),  and  the 
operating  system  (COSMOS  [RuM])  -  have  been  designed 
accordingly.  While  we  adopted  many  architectural  features 
of  this  educational  system,  the  internal  structure  was 
completely  redesigned  to  lend  support  to  the  implementation 
of  the  protection  system. 

The  simulation  is  coded  in  SIMULA  [Dah]  and  documented 
in  project  notes  [Shi].  The  hardware  configuration  consists 
of  nano  programmable  and  micro  programmable  central 
processors,  primary  memory  modules,  disk  systems  (each  one 
consisting  of  a  controller  and  a  drive),  and  terminals.  The 
various  components  are  represented  by  SIMULA  classes  and 
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their  number  is  parameterized.  The  virtual  address  space  is 
segmented  and  segment  numbers  are  absolute.  Segments  are 
referenced  via  descriptors  and  are  also  paged.  The  major 
operating  system  procedures  handle  initialization, 
scheduling,  CALL'S,  interrupts,  terminal  I/O,  disk  I/O, 
memory  recognition,  and  command  recognition.  The  protection 
system  consists  of  the  mediation  algorithms  affiliated  with 
the  four  level  interpreters,  the  data  structures  for 
identifiers  and  licenses,  and  the  routines  for  updating 
these  data  structures.  Various  formats  of  licenses  and 
identifiers  have  been  tried  out,  but  further  research  is 
needed  in  this  area. 

The  low  level  of  the  simulation  (SIMULA  code  is  used 
exclusively  for  the  interpretation  of  nano  instructions)  has 
focussed  our  attention  on  the  lack  of  hardware  support 
features  for  the  implementation  of  a  protection  system.  The 
periphery  is  particularly  weak  in  this  respect.  Along  these 
lines,  we  have  begun  the  design  of  a  protection  device  which 
is  to  be  interfaced  with  the  UNIBUS  of  a  PDP-11/60.  This 
device  is  meant  to  act  as  an  extension  of  the  protection 
system  (typically  located  in  the  CPU)  for  the  purposes  of 
mediating  operations  on  the  I/O  bus. 

CONCLUSION 

Licenses  are  equivalent  to  capabilities  and  access 
control  list  entries  in  the  sense  that  each  of  them  is  an 
encoding  of  the  protection  state,  where  the  encoding 


consists  of  two  of  the  three  quantities  subject,  access 
(algorithm),  and  object  (or  object-list).  In  the  case  of 
licenses  -  <subject;  object-list>  pairs  -,  the  protection 
state  is  affiliated  with  algorithms.  Mediation  involves  a 
context-sensitive  comparison  of  licenses  with  the  requesting 
subject  and  its  parameters.  Thus,  the  same  mechanism  serves 
for  access  control  and  parameter  checking.  (In  special 
cases,  authentication  may  be  viewed  as  an  instance  of 
parameter  checking,  e.g.  LOGIN(user  name,  password  or 
fingerprint).)  Licenses  support  the  implementation  of  data 
types  and  protected  subsystems  and  are  particularly  suited 
as  a  network  protection  mechanism.  Furthermore,  they  serve 
as  a  mechanism  for  monitoring  information  flow,  thus 
unifying  the  concepts  of  access  control  and  flow  control. 

The  notion  of  the  algorithmic  hierarchy  serves  as  a 
design  criterion  for  the  specification  of  licenses  on  the 
various  levels.  The  hierarchical  organization  of  licenses 
provides  a  unifying  framework  which  allows  efficiency 
considerations  to  dictate  the  design  on  each  level.  Some  of 
the  existing  hardware  protection  features  have  been  shown  to 
be  consistent  with  the  license  mechanism.  Since  the 
hierarchy  blurs  the  distinction  between  hardware  and 
software,  manageable  hardware  techniques  suggest  themselves 
as  remedies  to  some  of  the  more  intricate  software  problems. 
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Our  simulation  has  proven  the  feasibility  of 
implementing  licenses  in  a  controlled  environment.  Further 
research  is  needed  for  the  design  of  an  operational  system 
based  on  this  mechanism.  In  particular,  the  relation 
between  the  hierarchies'  of  objects  (bits,  fields,  words, 
records,  pages,  segments)  and  subjects  (processors, 
processes,  computations),  which  vary  considerably  from 
system  to  system,  deserves  careful  attention.  Furthermore, 
more  hardware  support  will  be  needed  for  licenses  on  the 
lower  levels.  In  any  event,  licenses  offer  several 
advantageous  properties  and  may  readily  be  applied  on  the 
network  and  command  level,  possibly  in  conjunction  with 
capability  and/or  access  control  mechanisms  on  the  lower 
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ABSTRACT  overall  operation  of  a  computer  system.  But  we 

were  also  painfully  aware  of  the  price  which  would 
While  the  adoption  of  an  implementation  pro-  have  to  be  paid  to  achieve  this  goal.  Clearly, 

Ject  for  an  operating  systems  course  is  certainly  this  project  could  only  be  successful  if  the  price 

beneficial,  non-trivial  projects  are  inherently  could  be  kept  affordable  and  if  the  benefit  to 

demanding  in  terms  of  student  efforts  and  com-  students  was  outstanding.  Ue  settled  on  a  number 

puter  costs.  This  paper  reports  on  a  project  of  necessary  criteria  for  keeping  the  price/ 

which  has  been  designed  to  keep  the  effort  for  benefit  ratio  low.  (1)  The  project  should  involve 

an  extensive  simulation  of  a  contemporary  system  an  enti re,  though  simple,  system  to  illustrate 

within  acceptable  limits.  The  project  involves  both  the  overall  operation  and  the  implementation 

both  a  hardware  simulator  and  an  operating  system,  details.  (2)  Computing  costs  should  be  kept 

and  a  considerable  reduction  of  the  overall  reasonable,  although  it  was  clear  from  tne  oeginning 

effort  could  be  achieved  by  enhancing  the  hardware  that  they  would  be  high.  (3)  The  system  snould 
withoperating  systems  support  feati.-es.  The  be  representative  of  contemporary  ones,  but  it 

design  criteria  as  well  as  the  characteristics  should  not  be  based  on  any  particular  brand.  This 

of  the  resulting  hardware  configuration  and  would  allow  the  use  of  advanced  effort-saving 

operating  system  are  presented,  and  the  value  of  architectures  and  also  simplify  the  introduction 

the  project  as  a  teaching  tool  is  discussed  of  implementation- independent  concepts.  (4)  The 

opportunity  should  be  used  to  introduce  students 

.INTRODUCTION  to  the  intrinsic  management  problems  of  large 

software  projects  which  are  typically  absent  in 
Since-  the  introduction  of  multi  programming,  academic  courses, 

operating  systems  have  become  a  respectable 

discipline  within  computer  science  and  most  From  the  first  criterion  we  concluded  that  the 

computer  science  programs  now  include  at  least  project  should  involve  both  a  hardware  simulator 

one  course  on  their  design  and  implementation.  and  an  operating  system.  This  decision,  wnich 

While  the  theoretical  material  of  such  a  course  resulted  in  an  integrated  design  methodology  for 

is  generally  agreed  upon  [1,2],  the  question  both  hardware  and  software,  allowed  us  to  design 

Of  whether  or  not  such  a  course  should  stress  a  machine  which  is  particularly  suited  for  the 

an  implementation  project,  and  what  its  nature  implementation  of  operating  systems.  It  is 

should  be,  has  continued  to  be  a  much  debated  termed  COS  for  Computer  for  Operating  Systems 

issue  [3, 4, 5, 6, 7, 8].  It  is  not  the  value  of  and  exists  in  two  versions  [9].  COS-1  consists 

such  a  project  which  is  being  debated.  Clearly,  only  of  a  processor  and  primary  memory;  it  serves 

the  experience  gained  from  an  implementation  to  get  the  project  started  fast.  The  downward 

cannot  be  substituted  by  even  the  most  illumi-  compatible  COS-2  includes  the  periphery,  but  its 

nating  lectures  or  homework  problems.  But  the  processor  is  also  enhanced  with  hardware  features 

price  for  a  non-trivial,  representative  opera-  (instructions,  interrupt  system,  registers)  whicn 

ting  systems  project  in  terms  of  student  efforts  support  the  operating  system.  In  view  of  tne 

and  computing  costs  is  formidable.  What  is  increasing  availability  of  microcode,  it  is  felt 

being  debated  is  whether  the  experience  gained  that  the  integrated  design  methodology  is  also 

from  such  a  project  is  worth  the  price.  very  promising  for  comnercial  systems.  In  any 

event,  it  cut  the  effort  for  implementing  tne 

During  the  academic  year  1974/75,  an  under-  operating  system  in  half  without  appreciably  corn- 

graduate  operating  systems  course  based  on  an  plicating  the  hardware  simulator  for  COS-2.  To 

implementation  project  was  developed,  carefully  cut  computing  costs,  it  was  decided  that  the 

Studied,  and  adopted  at  Rutgers  University.  system  should  not  process  symbolic  information; 

The  juniors  and  seniors  taking  this  course  have  we  estimated  that,  symbol ic  programs  would  require 

considerable  applications  programing  expertise,  about  20  times  more  storage  than  their  object 

but  have  had  little  exposure  to  systems  pro*  code  equivalents.  Instead,  a  crossassembler  was 

granting  and  system  organization.  Under  these  developed  and  made  available  to  students  in  order 

circumstances,  it  appeared  futile  to  attempt  to  ease  their  workload.  The  third  criterion 

to  convey  operating  systems  principles  without  resulted  in  an  operating  system  whose  mode  of 

first  providing  an  intuitive  understanding  of  the  operation  is  similar  to  the  "THE"-Multiprogran»iiing 

System  [10].  This  system  is  written  in  assembly 
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language,  but  the  assembly  language  has  the 
appearance  of  an  ALGOL-derivative  in  order 
to  relate  to  the  notation  of  most  textbooks  on 
operating  systems.  The  system  is  named  COSMOS, 
an  abbreviation  for  COS  Mul  tiprogranming  Operating 
System  [11].  COSMOS  spools  user  jobs  from  a  card- 
reader  to  a  drum.  Whenever  there  is  sufficient 
primary  memory  available,  a  job  is  loaded  for 
execution.  Operating  systems  calls  are  avail¬ 
able  for  I/O  operations  and  termination.  After 
the  latter,  a  job’s  output  is  printed  on  the  line- 
printer  with  performance  statistics.  In  satisfac¬ 
tion  of  the  fourth  criterion,  COSMO!  is  structured 
in  levels  of  abstraction  and  the  entire  project  is 
assigned  incrementally.  Students  work  in  teams  of 
two  and  often  experience  for  the  first  time  that 
they  have  to  live  with  code  which  they  wrote  two 
months  earlier. 

The  project  was  successfully  completed  by 
most  students  who  took  the  course  during  the  last 
two  years.  Except  for  the  crossassembler,  the 
entire  system  is  implemented  by  a  team  of  two  stu¬ 
dents,  but  detailed  design  specifications  in  terms 
of  reference  manuals  and  flowcharts  are  handed 
out.  The  project  is  structured  in  the  form  of  six 
assignments,  each  of  which  build  on  all  previous 
ones: 

1.  Simulation  and  testing  of  COS-1. 

2.  Simulation  and  testing  of  COS-2. 

3.  Run  of  a  stand-alone  periphery  test  program. 

4.  Testing  of  the  COSMOS  spooling  system. 

5.  Run  of  a  single  user  job  under  COSMOS. 

6.  Evaluation  of  runs  of  batches  of  user  jobs. 

The  first  three  assignments  represent  the  hardware 
simulator  and  are  completed  after  about  one  month. 
The  last  three  assignments  representing  the  operat- 
inq  system  require  another  month  for  completion. 
During  the  last  third  of  the  semester,  advanced 
concepts  are  presented  as  solutions  to  the  inade¬ 
quacies  of  the  implemented  system.  Due  to  the 
expertise  gained  from  the  irr:  lementation,  students 
tend  to  appreciate  the  value  of  more  abstract 
principles  which  can  thus  be  dealt  with  at  a  rapid 
pace.  It  is  this  third  phase  of  the  course  which 
indicates  that  the  benefits  derived  from  the  pro¬ 
ject  more  than  justify  its  price.  The  feedback 
and  the  entnusiasm  of  students  corroborate  this 
indication. 


THE  HARDWARE  AND  ITS  SIMULATOR 

The  configuration  of  the  simulated  COS-2 
hardware  complex  has  been  designed  to  support 
the  operation  of  the  COSMOS  system.  It  is 
illustrated  in  Figure  1.  Only  essential  devices 
have  been  included,  but  both  modes  of  direct 
I/O  (cardreader  and  lineprinter)  and  indirect 
I/O  (Drum  controller)  are  represented.  Primary 
memory  assumes  the  central  position  for  data 
transfers,  while  the  CPU  (and  its  console) 
serves  as  the  system's  control  center.  While  this 
configuration  is  representative  of  contemporary 
minicomputer  systems,  its  restriction  to  essential 
devices  also  allows  for  the  implementation  of  a 
detailed  simulator  within  a  reasonable  period  of 
time. 


The  simulator  consists  of  four  major  modules: 
a  subroutine  for  the  instruction  execution  cycle, 
a  main  driver  which  corresponds  to  the  console 
and  repeatedly  calls  the  execution  cycle  subroutine, 
a  conmon  module  containing  the  storage  declarations  ' 
and  constants  like  masks  and  fields,  and  another 
subroutine  simulating  the  combined  cardreader  and  . 
crossassembler  (see  below).  The  drum  system  is 
simulated  by  the  instruction  cycle  subroutine  which  1 
counts  real  time  in  terms  of  the  number  of  instruc-  ' 
tions  executed.  The  simulator  may  be  written  in 
any  high-level  language.  In  the  past  two  years, 
FORTRAN  was  chosen  for  reasons  specific  to  our 
environment,  but  also  because  this  lowest  of  all 
high-level  languages  quite  appropriately  reflects 
the  nature  of  hardware  operations.  In  fact,  many 
of  the  FORTRAN  statements  may  be  interpreted  as 
microinstructions,  thus  lending  themselves  to  the 
introduction  of  firmware.  The  final  versions  of 
the  COS-2  simulator  without  the  cardreader/cross-  j 
assembler  subroutine  (which  was  written  in  PL/ I) 
consisted  of  about  500  FORTRAN  STATEMENTS. 

CPU  AND  PRIMARY  MEMORY 

The  CPU  contains  many  of  the  standard  features 
for  its  task  of  instruction  execution  and  system  j 
supervision.  Four  registers,  program  counter, 
instruction  register,  accumulator,  and  index  regis-  • 
ter,  serve  the  obvious  purposes.  For  simplicity, 
a  fixed,  single-word  instruction  format  has  been 
adopted.  In  addition  to  the  operation  code  and 
four  addressing  modes  (indexing  and  indirection 
in  any  combination),  an  instruction  contains  two 
address  fields.  The  addition  of  a  second  address 
field  to  the  originally  contemplated  single¬ 
address  format  (a  seemingly  unimportant  detail) 
had  a  considerable  impact  on  both  code  compaction  . 
(about  30%)  and  code  legibility.  The  latter  is 
due  to  the  fact  that,  in  assembly  language,  many 
quantities  can  be  referred  to  be  meaningful  < 

symbolic  names,  rather  than  by  the  semantically  ; 
irrelevant  names  of  the  registers  in  which  they 
reside.  The  operating  system  is  aided  in  its  task 
by  four  more  CPU  registers:  interrupt  and  trap 
register,  arming  register,  mode  register,  and  state 
pointer  register.  The  latter  contains  a  pointer 
to  the  process  state  record  (PSR),  the  data  struc-  ' 
ture  describing  the  state  of  the  currently  running  ' 
process  (Figure  2).  Interrupts  and  traps  are  ser 
viced  by  a  multi-level  priority  interrupt  system  j 
which  saves  the  entire  state  of  the  interrupted 
process  and  loads  the  initial  state  of  the  inter¬ 
rupt  service  routine.  This  control  transition  is 
performed  completely  in  hardware  and  makes  use  of 
both  the  state  pointer  register  and  an  interrupt 
transfer  vector  in  standard  low  core  locations. 

Virtual  memory  is  supported  by  a  paging  map. 

The  virtual  address  space  covers  IK  words  con¬ 
sisting  of  8  pages  of  128  words  each.  Words, 
both  primary  memory  locations  and  registers,  are  1 
36  bits  long;  they  have  been  dimensioned  after 
the  integer  size  of  the  IBM  370  system  on  which 
the  simulator  is  developed  and  run.  Primary 
memory  consists  of  2K  words  or  16  pages  of  128 
words  each.  It  is  accessed  from  the  CPU  via  the 
paging  map.  Page  0  contains  a  number  of  standard 
locations  ("low  core")  for  communications  among 
the  various  devices.  These  standard  locations 
are  used  for  bootstrapping,  timers,  the  drum 
queue  pointer,  and  the  interrupt  transfer  vector. 
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Figure  1.  COS/2  system  configuration. 


Figure  2.  The  format  of  a  process  state  record  (PSR). 
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Figure  3.  The  standard  format  for  COSMOS  queues. 
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The  role  of  the  console  has  been  stressed  for 
pedagogical  reasons.  First,  its  switches  and  indi¬ 
cators  allow  for  a  completely  manual  operation  of 
the  entire  hardware  complex.  Aided  by  a  break¬ 
point  facility,  a  student  can  thus  slow  down  the 
operations  of  the  system  and  inspect  its  state  via 
the  indicators  (printed  out  by  the  main  driver). 

In  this  "hands-on"  mode  of  operation,  the  student 
can  debug  his/her  programs  (including  the  simula¬ 
tor,  i.e.  his/her  hardware  configuration)  and  gain 
familiarity  with  the  systemin  a  manner  compar¬ 
able  to  a  systems  progranmer  or  a  programmer/ 
operator  of  the  1950' s.  On  the  other  hand,  no  real 
hardware  must  be  provided,  thus  avoiding  scheduling 
problems  as  well  as  hardware  failures.  Second, 
the  bootstrap  mechanism  which  loads  stand-alone 
programs  (including  the  operating  system)  from  the 
cardreader  into  primary  memory  can  be  activated 
from  the  console.  Since  most  students'  know¬ 
ledge  about  operating  systems  is  restricted  to 
external  characteristics  like  command  language 
and  operating  systems  calii,  the  concept  of  how  a 
system  is  brought  up  often  challenges  their 
imagination.  We  found  that  the  simulation  not  only 
reduced  the  effort  for  conveying  this  concept,  but 
also  illustrated  the  functional  equivalence  of 
hardware  and  systems  software.  This  equivalence 
is  an  important  notion,  since  it  lends  itself  to 
the  introduction  of  microcode.  Microcode,  in  turn, 
justifies  the  implementations  of  a  nunber  of 
operating  system  functions  as  instructions.  The 
inclusion  of  these  functions  in  the  instruction 
set  resulted  in  a  considerable  simplification  of 
the  COSMOS  code  and,  thus,  aided  in  keeping  the 
programming  effort  within  reasonable  bounds. 

In  addition  to  a  fairly  standard  complement  of 
about  40  instructions  for  data  movements,  arithmetic 
and  logic  operations,  branching,  and  input/output, 
the  instruction  set  contains  13  operating  systems 
support  instructions.  The  criteria  for  their 
inclusion  were  high  execution  frequency  and/or 
potential  for  code  compaction.  Neither  the  instruc¬ 
tion  set  nor  the  instruction  format  were  frozen 
until  a  version  of  COSMOS  had  been  coded  in  a  hypo¬ 
thetical  open-ended  language  which  eventually  con¬ 
verged  to  the  assembly  language.  This  approach 
allowed  for  a  frequency  analysis  of  instructions 
and  resulted  in  the  deletion  of  superfluous  ones 
as  well  as  in  the  adoption  of  the  operating 
systems  support  instructions. 

According  to  Werkheiser's  classification 
[12],  miniprimitives  (equivalent  in  power  to 
conventional  machine  instructions)  and  midiprimi¬ 
tives  (equivalent  to  the  system  macro)  evolved. 

The  former  were  designed  to  support  the  manipu¬ 
lation  of  the  COSMOS  data  structures,  in  parti¬ 
cular  bit-tables  and  queues.  Two  instructions 
inspect  and  conditionally  update  bit-tables 
and  indicate  their  action  upon  return.  They 
are  used  for  the  allocation  of  drum  and  core 
pages.  A  standard  format  for  queues  was  adopted 
which  includes  both  linkage  pointers  and  status 
words  (Figure  3).  Operations  to  get,  return, 
append,  insert,  and  find  a  record  are  supported. 

They  are  used  primarily  to  manipulate  process 
state  records  and  drum  transfer  records  (DTR's, 
describing  requests  for  drum  I/OTi  Midiprimitives 
are  included  to  support  level  crossings.  User 
processes  enter  system  processes  via  an  operating 


system  call  instruction  (OS  CALL)  which  causes  a 
trap.  Traps  as  well  as  interrupts  save  the  state 
of  the  current  process  in  its  PSR  and  load  the 
state  of  the  next  process  from  its  PSR.  An  iden¬ 
tical  operation  is  performed  by  the  instruction 
SWITCH  PROCESS,  but  it  obtains  a  pointer  to 
next  PSR  from  a  register  rather  than  low  core. 

Since  this  operation  provides  the  only  means  of 
setting  the  paging  map,  it  constitutes  a  central 
part  of  the  protection  mechanism  in  COSMOS. 

Peripheral  Devices 

The  complexity  of  the  peripheral  devices  has 
been  reduced  to  a  minimum.  The  cardreader  con¬ 
tains  a  hopper  which  is  filled  with  the  decks  of 
a  number  of  jobs.  Each  deck  consists  of  a  JOB 
card,  followed  by  program  cards,  a  DATA  card  and 
input  data  cards  (optional),  and  an  END  card. 

The  information  on  a  card  is  encoded  in  32  bits 
and  corresponds  to  a  machine  word.  Upon  execution 
of  the  instruction  READ  CARD  the  contents  of  the 
next  card  in  the  hopper  are  transferred  to  the 
accumulator  and  the  instruction  skips  a  variable 
number  of  times  depending  on  the  type  of  card 
(or  lack  thereof).  The  cardreader  also  serves  as 
the  input  device  for  bootstrapping. 

The  lineprinter  can  be  activated  via  two 
instructions.  PRINT  LINE  prints  the  contents  of 
the  accumulator  as  an  eight-digit  hexadecimal 
integer  after  the  printout  paper  has  been  advanced 
one  line.  Thus,  printout  will  typically  consist 
of  a  single  column  of  integers.  A  special  pur¬ 
pose  instruction,  HEADER,  is  provided  to  print 
the  header  preceding  the  output  of  a  user  job. 
HEADER  prints  several  lines  of  symbolic  and 
numerical  information  which  is  extracted  from  a 
process  state  record.  The  information  contains 
job  statistics  and  possibly  indications  of  an 
abnormal  termination. 

The  drun  system  represents  an  indirect  I/O 
device.  The  storage  capacity  is  16  pages  of  128 
words.  Transfers  are  on  a  page  basis  and  are 
controlled  by  the  drum  controller  which  is  started 
from  the  CPU  by  executing  a  START  DRUM  instruction. 
The  controller  obtains  the  transfer  parameters 
from  a  drun  transfer  record  pointed  to  by  a  stan¬ 
dard  location  in  low  core.  The  controller  informs 
the  CPU  about  the  completion  of  a  transfer  by 
issuing  an  interrupt. 


THE  COSMOS  OPERATING  SYSTEM 

Most  contemporary  definitions  identify 
operating  systems  as  programs,  i.e.  software. 

We  feel  that  these  definitions  are  too  narrow, 
that  they  stress  an  implementation  aspect  rather 
than  concentrating  on  functional  aspects.  We 
prefer  to  think  of  an  operating  system  as  a  system 
of  components  which  operates  a  computer  system  in 
a  user-oriented  and  efficient  manner.  Whether 
certain  functional  components  are  represented  by 
hardware,  microcode,  software,  or  even  a  human 
operator,  will  be  dictated  by  the  current  state 
of  technology.  An  alternative  to  the  traditional 
software  overlay  techniques  has  long  been  offered 
in  hardware  supported  virtual  memories,  and  in 
trillion-bit  memories  mechanical  devices  now  cost- 
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effectively' perform  the  traditionally  human  task  of 
mounting  removable  storage  media.  In  view  of  the 
seemingly  unsurmountable  difficulties  encountered 
In  large  software  systems,  it  appears  worthwhile 
;to  reconsider  the  assignment  of  operating  systems 
functions  to  specific  implementation  media. 

Compared  to  conmercial  systems,  our  educa¬ 
tional  COSMOS  system  may  well  be  characterized  as 
a  toy  system.  But  there  is  at  least  one  thing 
which  they  have  in  common:  the  effort  required 
for  their  implementations  approaches  the  limit  of 
the  available  manpower.  0S/360  devoured  5000 
man-years  for  its  design,  construction,  and  docu¬ 
mentation  [13].  This  must  be  compared  to  a  couple 
of  man-months  which  can  be  put  in  by  a  team  of  two 
students  registered  for  a  normal  load  of  four 
courses  during  one  semester.  Clearly,  this 
analogy  must  not  be  pushed  too  far.  But  it 
vividly  demonstrates  the  effect  of  measures 
which  result  in  cutting  the  required  effort  in 
half.  Since  the  implementation  project  includes 
both  a  hardware  simulator  and  COSMOS  code,  one 
important  design  parameter  concerned  the  distribu¬ 
tion  of  functional  capabilities  over  hardware  and 
software.  We  believe  that  the  successful  comple¬ 
tion  of  this  project  within  one  semester  by  almost 
all  students  is  a  direct  consequence  of  our  inte¬ 
grated  design  methodology  and  the  resulting  sim¬ 
plification  of  the  overall  system. 

COSMOS  is  coded  in  assembly  language  and  its 
loadmodule  fits  into  a  single  virtual  address 
space  (IK  words).  The  actual  code,  as  opposed  to 
data  structures  and  buffers,  consists  of  less  than 
500  instructions. 


Mode  of  Operation 


In  many  respects,  the  mode  of  operation  in 
COSMOS  is  similar  to  Dijkstra’s  "THE"-Multi- 
programmi ng  System.  Unnecessary  sophistication 
has  been  sacrificed  in  order  to  keep  the  imple¬ 
mentation  effort  manageable.  For  instance,  user 
jobs  cannot  leave  information  behind  them  in  the 
system  after  termination.  For  the  same  reason, 
no  symbolic  information  can  be  processed;  the 
system  relies  on  a  crossassembler,  which  is  coupled 
with  the  cardreader,  for  symbol  manipulation. 
Furthermore,  only  one  language  processor  (for 
assembly  language)  is  available,  and  a  standard 
command  sequence  is  implied  (rather  than  pro¬ 
viding  a  more  versatile  conmand  processor). 


COSMOS  is  brought  up  by  bootstrapping  from 
the  cardreader.  After  initialization,  it  enters 
the  stationary  mode  in  which  it  accepts  user 
jobs  from  the  cardreader  for  processing.  A  job 
must  be  submitted  in  the  following  order:  J08 
card,  program,  DATA  card  and  input  data  (optional), 
and  END  card.  Syntactically  incorrect  jobs  are 
flushed  by  the  crossassembler  and  are  not  passed 
on  to  the  cardreader.  At  any  one  time,  several 
jobs  may  be  in  the  system  at  various  stages  of 
completion.  Any  one  job,  however,  will  be  pro¬ 
cessed  in  the  following  sequence.  After  being 
spooled  to  the  drum,  a  job's  program  is  loaded 
into  core  and  then  given  control  of  the  CPU. 

For  Input,  the  program  may  execute  an  OS  CALL 
which  will  provide  it  with  the  next  input  word 
from  the  input  data  page  on  the  drum.  Another 
OS  CALL  causes  the  transfer  of  an  output  word  to 


the  output  data  page  on  the  drum.  After  termina¬ 
tion  of  a  user  job,  its  output  is  printed  on  the 
lineprinter  together  with  some  statistics.  This 
default  sequence  renders  an  explicit  command  pro¬ 
cessor  unnecessary;  its  function  is  performed  by 
the  input  spooling  system.  After  spooling  in  the 
last  user  job,  COSMOS  will  continue  to  process  the 
resident  jobs  and  halt  after  the  last  one  has 
terminated. 

Crossassembler 

COSMOS  is  written  in  the  assembly  language 
of  COS  [14].  Thus,  there  is  a  one-to-one  corres¬ 
pondence  between  assembly  language  statements 
(except  pseudo  operations)  and  machine  instruc¬ 
tions  which  have  been  implemented  in  detail  in  the 
simulator.  On  the  other  hand,  the  language  has 
been  given  the  flavor  of  an  ALGOL-like  system  pro¬ 
gramming  language  by  using  meaningful  mnemonics 
and  by  enclosing  the  address  fields  in  paren¬ 
theses,  much  like  parameters  in  a  subroutine  call. 
See  Figure  5  for  a  sample  program.  The  syntax  of 
the  assembly  language  has  been  adopted  for  purely 
pedagogical  reasons,  since  many  textbooks  use  some 
sort  of  ALGOL-derivative  for  the  illustration  of 
algorithms.  During  the  first  year,  when  the  cross- 
assembler  accepted  the  standard  three-letter 
mnemonics,  many  students  found  it  difficult  to 
relate  textbook  examples  to  their  own  machine 
language  code.  The  simple  change  in  the  syntax 
apparently  resol .ed  that  problem  during  the  last 
semester. 

If  programs  were  entered  via  the  cardreader 
in  symbolic  form,  they  would  require  about  20 
times  more  storage  space  than  machine  code.  To 
keep  the  cost  of  a  simulation  run  down,  it  was 
decided  to  enter  only  binary  information  via  the 
cardreader.  This  is  accomplished  by  providing  a 
crossassembler  whose  output  is  coupled  with  the 
cardreader.  Students  are  provided  with  a  load- 
module  of  the  crossassembler  which  is  written 
in  PL/I.  It  is  written  as  a  subroutine  which, 
when  called,  returns  the  next  word  of  the  pre¬ 
viously  assembled  job  as  well  as  an  indication 
about  the  nature  of  the  corresponding  card  (instruc 
tion,  control  card,  etc.).  If  no  more  object  code 
words  are  available,  crossassembler  reads  in  the 
next  job  (symbolic  program,  input  data,  and  control 
cards),  assembles  it,  and  returns  the  first  word, 
the  JOB  card.  To  the  hardware  simulator,  the  cross 
assembler  subroutine  appears  to  represent  the  card- 
reader,  since  it  returns  the  equivalent  of  one  card 
upon  each  call.  In  a  simulation  run,  the  input 
data  to  the  cardreader/crossassembler  subroutine 
consists  of  the  COSMOS  job  (which  will  be  boot¬ 
strapped)  followed  by  an  arbitrary  number  of  user 
jobs. 

COSMOS  Structure 

COSMOS  is  structured  in  levels  of  abstraction 
which  are  depicted  in  Figure  4.  The  assignment  of 
functions  to  particular  levels  evolved  from  a 
number  of  considerations.  The  mode  of  operation 
determined  the  high-level  functions  of  spooling, 
1/0,  loading,  termination,  and  printing.  The 
concept  of  multiprogramming  is  implemented  by  the 
SCHEDULER  one  level  below  so  that  the  high-level 
functions  can  be  scheduled  like  a  user  job.  The 
interrupt  routines  in  level  4  provide  real-time 
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dependence  for  all  higher  levels.  Drum-multl- 
progranming,  realized  by  manipulating  drum  trans¬ 
fer  records  in  the  drum  queue,  is  real-time  depen¬ 
dent  and  thus  one  level  below,  the  notion  of  a 
process  may  be  defined  abstractly,  but  in  any  im¬ 
plementation  it  is  simply  the  quantity  described 
by  the  corresponding  operating  system  data  struc¬ 
ture,  e.g.  the  PSR.  In  manipulating  these  data 
structures,  level  2  provides  the  process  notion. 
Finally,  data  structures  must  be  allocated  before 
they  can  be  manipulated.  Thus,  storage  alloca¬ 
tion  has  been  assigned  to  the  lowest  level  in  the 
hierarchy. 

The  assignment  of  functions  of  the  hier¬ 
archy  in  Figure  4  evolved  gradually  during  the 
course  of  several  top-down  and  bottom-up  design 
iterations.  Tnis  design  methodology  also  involved 
decisions  about  the  implementation  media  for  the 
various  modules.  All  modules  in  levels  1  and  2  are 
implemented  as  instructions,  thus  considerably  sim¬ 
plifying  and  compacting  the  COSMOS  code.  Sema¬ 
phore  operations  were  not  included  since  they 
are  not  representative  of  conmercial  systems  which 
are  graduates  are  most  likely  to  deal  with. 

Instead,  they  are  introduced  at  the  end  of  the 
semester  as  elegant  mechanisms  for  handling  synchro¬ 
nization  problems.  The  latter  are  emphasized  by 
level  3  which  is  implemented  as  a  shared  (and 
interruptible)  subroutine.  All  modules  above 
level  3  are  implemented  as  processes,  i.e.  programs 
whose  execution  state  is  described  by  a  PSR. 

The  SWITCH  PROCESS  instruction  passes  control 
among  processes.  A  similar  operation  is  performed 
by  the  interrupt  system  for  passing  control  to 
processes  in  level  4.  These  interrupt  processes, 
however,  use  the  standard  SWITCH  PROCESS  instruc¬ 
tion  to  return  to  the  interrupted  process. 

Interrupt  processes  may  be  interrupted  by  an 
interrupt  of  higher  priority.  The  SCHEDULER  in 
level  5  initially  obtains  control  from  the  boot¬ 
strap  mechanism.  Thereafter,  the  control  transfer 
to  a  schedulable  process  in  level  6  and  the  return 
to  the  SCHEDULER  is  accomplished  by  SWITCH  PROCESS 
INSTRUCTIONS.  With  respect  to  scheduling,  we 
followed  the  basic  guideline  that  mechanisms  should 
be  implemented  in  hardware  while  policy  aspects  are 
more  flexible  in  a  software  implementation  [15,  16]. 
The  task  of  activating,  deactivating,  blocking,  and 
unblocking  processes,  accomplished  by  setting  and/ 
or  resetting  bits  in  the  status  words  of  the  cor¬ 
responding  PSR's,  is  distributed  among  the  COSMOS 
processes.  For  example,  since  loading  of  a  job 
depends  on  the  successful  completion  of  the 
spooling  operation,  the  spooling  process  which 
finishes  this  operation  will  activate  the  loader 
on  behalf  of  this  job. 

Processes  and  Their  Functions 

After  system  initialization,  the  SCHEDULER 
loops  scanning  the  process  state  record  queue  and 
pickinq  the  ready  (i.e.  active,  but  not  blocked) 
job  with  the  highest  priority  for  execution.  The 
search  is  performed  by  the  FIND  RECORD  instruction 
which  compares  the  second  parameter  under  a  mask 
in  the  accumulator  with  the  status  words  in  the 
queue  (Figure  5).  FIND  RECORD  skips  if  a  match 
is  found  and  returns  a  pointer  to  the  matching 
PSR  in  the  index  register.  SWITCH  PROCESS  trans¬ 
fers  control  to  the  process  specified  by  the 
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pointer  in  the  index  register;  its  address  field 
denotes  the  address  at  which  the  process  relin-  ] 
guishing  control  will  start  execution  at  its  next 
activation.  If  no  processes  are  ready,  the  SCHEDU-  • 
LER  checks  whether  there  are  any  blocked  ones;  if 
not,  the  simulation  run  is  terminated  by  executing 
a  HALT.  1 

The  Drum  Interrupt  Process  cleans  up  after  a 
transfer  and  restarts  the  drum  if  more  requests 
are  pending.  It  also  supports  the  FILE  SYSTEM  in 
performing  user  I/O.  The  Trap  Process  handles  OS 
CALL'S  much  like  0S/360  as  well  as  protection  vio¬ 
lations.  User  programs  exceeding  their  time  limits  | 
(set  by  the  SCHEDULER)  lose  control  to  the  Timer  t 
Interrupt  Process  when  the  timer  goes  off. 

A  double-buffering  scheme  with  dynamic  buffer 
allocation  is  used  for  spooling  jobs  from  the 
cardreader  to  the  drum.  The  two  processes  RCARD  and 
WCARD  read  a  page  into  core  and  write  it  to  the 
drum  respectively.  They  synchronize  each  other  and 
also  initialize  a  PSR  for  the  arriving  job.  After 
a  job  has  been  spooled  in,  the  LOADER  will  trans¬ 
fer  its  code  to  primary  memory  as  soon  as  there 
are  enough  pages  available.  A  simple  statis  pre- 
loading  scheme  is  used.  User  jobs  read  input  data 
and  write  output  data  sequentially  by  executing  the  • 
appropriate  OS  CALL'S  which  in  turn  cause  an  activa¬ 
tion  of  the  FILE  SYSTEM.  Buffers  required  for  the 
input  or  output  page  are  allocated  dynamically  and 
their  locations  as  well  as  the  access  indices  are  : 
maintained  in  the  PSR  of  the  requesting  user.  The  • 
end  of  execution  of  a  user  job  is  signaled  to 
COSMOS  by  another  OS  CALL.  The  TERMINATOR  WILL  sub-  ; 
sequently  release  all  allocated  resources  except 
for  the  output  data  page.  Jobs  may  also  terminate 
abnormally  by  executing  an  illegal  instruction,  by 
causing  a  memory  violation,  or  by  exceeding  their 
quanta.  A  user  job's  output  is  preceded  by  statis-  ) 
tics  and  printed  by  the  PRINT  process  which  finally  ; 
returns  the  job's  PSR  to  the  freelist. 

Conclusion  j 

The  COSMOS  project  has  proven  itself  as  a 
viable  teaching  tool.  Its  scope  is  modest,  yet  it 
is  representative  of  contemporary  systems,  and 
its  structured  and  integrated  design  utilizes 
advanced  concepts.  While  the  implementation  of  the  • 
hardware  simulator  provides  insight  into  the  under¬ 
lying  mechanisms,  the  coding  of  the  operating  system 
stresses  the  interrelationship  of  these  mechanisms 
in  forming  an  operational  computer  system.  The  per¬ 
formance  of  this  system  can  be  evaluated  as  a 
function  of  hardware  and  software  parameters  by 
running  batches  of  user  jobs.  Thus,  the  project 
provides  a  framework  for  the  study  of  both  design 
and  system  behavior. 

Despite  its  numerous  benefits,  the  project 
could  not  have  succeeded  without  the  extensive 
design  and  documentation  efforts  which  focussed 
on  a  reduction  of  the  implementation  effort  with¬ 
out  trivializing  the  system.  The  applied  inte¬ 
grated  design  methodology,  which  resulted  in  an 
enhancement  of  the  hardware  for  operating  systems  ! 
support,  appears  to  be  applicable  to  real  systems. 

At  a  time  when  it  is  not  uncommon  that  50  percent 
of  the  cycles  of  a  "general-purpose"  system  are 
consumed  by  operating  systems  code,  it  may  well  be 
justified  to  replace  the  general-purpose  processor 
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Figure  4.  Levels  of  abstraction  in  COSMOS. 
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Figure  5.  Assembly  language  code  for  the  COSMOS  scheduler. 
SCHEDULER 


INITIALIZATION  (GETS  CONTROL  FROM  BOOTSTRAP  LOADER) 


SIINIT: 


XR  LOAD 
SP*XR; 

IT  RESET 
AR  RESET 
AR  SET 
AC  LOAD 


*  SCHEDULING 


SjENTRY : 


MOVE 

FIND  RECORD 
GO  TO 


(LCSSCH); 

(NEGONE}; 

(NEGONE); 

(INTBITS); 

(ABIT); 


(LC$RTC,  SSQUANT); 
(PSRQ,  ABB  ITS); 
(SJACHECK) ; 


SWITCH  PROCESS  (SSENTRY) ; 

*  CHECK  FOR  BATCH  COMPLETION 

* 

SJACHECK:  F'ND  RECORD  (PSRQ,  ABIT); 
HALT; 

SOTO  (SJENTRY); 


INITIALIZE  SP 
CLEAR  IT 
PI  EAR  AR 

ENABLE  AND  ARM  LEVELS 
INIT  PATTERN  FOR  MATCHING 


SET  TIMER 

FIND  READY  PROCESS 

NO  PROCESSES  READY 

PASS  CONTROL  TO  READY  PROC 


*  LOCAL  VARIABLES 
SJQUANT :  CONSTANT 


( ' FFFFEFFF) ; 


FIND  AN  ACTIVE  PROCESS 
NONE,  BATCH  COMPLETED 
OBVIOUSLY  BLOCKED,  KEEP 
SCANNING  PSRQ  WHILE  WAITING  FOR  ANY 
PROCESS  TO  BECOME  READY 


LARGE  NEGATIVE  QUANTUM 


by- a  special-purpose  operating  systems  processor. 
Microcode  technology  is  ready  for  this  application. 

Students  have  responded  quite  positively  to 
the  adoption  of  the  project.  Several  extensions 
have  been  designed  and  partially  implemented  in 
independent  study  projects.  A  further,  interactive 
derivative  has  been  written  in  SIMULA  on  a  PDP-10 
and  currently  serves  as  the  framework  for  graduate 
research  in  the  area  of  protection. 
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1 NTRODU  r i ON 


COS-1  i:  the  basic  nude ;  of  the  COS  (Computers  for  Operation  Systems)  series. 
It  consists  of  a  central  processing  unit  (CPU)  and  a  2K-mo<hile  of  32-:  It 
primary  memory  (PW  which  Is  addressed  from  0  to  ’  •  larger  addresses  are 
cut  bud:  to’  H’ bits  and  location  0  '$  inaccessible).  COS-1  is  a  oaqinu  system 
8nd  features  direct,  indirect,  and  indexed  addressing  nodes.  The  paq<  Ize  is 
128  words  (7-bit  displacement)  and  the  virtual  address  space  contains  eight 
panes  Thus,  virtual  addresses  are  ten  hits  lone, 

Arithmetic  is  pr -formed  in  two  s  complement  form  on  32-bit  integers-  besides 
arithmetic  operations,  the  instruction  tepe -tol re  includes  looical,  branching 
end  register  operations  as  well  as  a  HALT  instruction. 


2  ARCHITECTURE 

The  four  major  functions  of  the  CPI'  aie  reflected  in  the  system  archiecture 
Instruction  execution  is  controlled  by  the  control  unit  (CU).  Arltnm  ,1c  and 
logical  operation..  a  "G  perfo-med  In  the  ar'  thineTfc  {ncf  logical  un ft  (hLU) 
the  local  storare  unit  (L5U)  contains  the  relo'catTon "map  aruTotHer” real s ters , 
The  s/sferr.  nay  Si  operated  manually  via  the  console.  Figure  1  illustrates. 
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Figure  1:  The  COS-  archite  .'*e 


The  32-bit  reaisters  in  the  LSI)  serve  the  following  functions: 

The  program  counter  (PC)  contains  the  virtual  address  of  the  current  (or  the 
next)  TnstructT(Tn7"0nly  the  rightmost  ten  bits  are  significant. 

The  instruction  register  (Id)  contains  the  currentlv  executed  instruction. 

The  accumulator  (AC)  provides  temporary  storaqe  for  intermediate  operands, 

The  index  register  (XR)  is  used  primarily  for  address  computations  (indexinq). 
It  may  aTso  be  used  for  temporary  storaqe. 

The  etqht  relocation  registers  (RRO  through  RR7),  or  map,  provide  the  current 
mapping  of  virtual  into  physical  page  numbers.  Figure  2  illustrates  their  role 
in  the  mapping  process.  With  2K  of  PH,  the  least  significant  four  bits  suffice 
to  specify  any  physical  page  number.  All  other  bits  are  ionored,  except  for 
bit  0  which  -  when  set  -  Indicates  an  invalid  entry.  Accesses  via  Invalid 
entries  are  treated  as  memory  violations. 


10-bit  victual  address 
3-bit  pane  7-bit  displacement 


4-bit  page  7-blt  ilsplacement 
11-bit  physict.  address 


Figure  ?:  Happing  of  a  virtual  address 
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3  INSTRUCTION  FORMAT 

A  double  address  Instruction  format  has  been  adopted  for  the  COS  series. 
However,  of  the  two  addresses  embedded  in  the  instruction,  onlv  address  A2 
may  be  modified  via  indirection  and/or  indexlno  (Fiuure  3).  For  address  Ai , 
direct  addressing  mode  must  be  used* 


Figure  3:  COS  instruction  format. 


An  instruction  contains  four  different  fields: 

The  operation  code  (OPCODE)  field  is  six  bits  iono.  The  two  leftmost  bits 
specify  one  of~four  instruction  types. 

The  two  address  fields^  (A1  and  A2)  span  ten  bits  each.  Thus,  every  virtual 
location  can  be  addressed  directly. 

The  addressing  mode  field  consists  of  the  index  bit  (X)  and  the  induct 
bit  (!).  Thus,  tHere  are  four  different  addresslnq "nodes  with  respect  ^Eo 
address  A2: 


A2  addressing  mode 


0  0  di  rect 

0  1  indexed 

1  0  indirect  (one  level  only) 

1  1  Indirect  before  indexed  (one  level  of  indirection) 


Figure  4  sketches  the  algori.nm  for  the  generation  of  the  effective  virtual 
addresses  VI  and  V2.  MAP(V2)  denotes  the  physical  address  of  the  Ind*  *ect 
location.  Since  some  instructions  do  not  make  use  of  both  addresses,  the 
generation  of  the  effective  physical  addresses  LI  and  L2  is  requested  only 
when  needed,  l.e.  after  the  processor  dispatched  on  the  operation  code 


address  fields 
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initialization  of  VI  and  72 
indirection  specified? 
qet  indirect  location 
indexing  specified? 
add  XR 

virtual  effective  addresses 


Figure  4:  Algorithm  for  *he  virtual  effective  address  generation. 


4  INSTRUCTION  REPERTOIRE 

In  the  COS  series.  Instructions  are  grouped  according  to  four  types.  The 
type  of  an  Instruction  Is  encoded  in  the  leftmost  two  bits  of  its  opera¬ 
tion  code: 


leftmost  bits  tj£pe 


00  0:  reqlster  and  transfer 

01  1:  arithmetic,  logical  and  branchlna 

10  2:  input-output 

1  l  3:  operating  system*  support 


In  the  following  functional  description,  Ll  and  L2  represent  the  physical 
effective  addresses  obtained  from  A1  and  A2  via  the  effective  virtual 
address  generation  and  a  subsequent  mapping-  Except  for  the  HALT  Instruc¬ 
tion  (type  2),  the  COS-1  instruction  set  contains  only  instructions  of 
the  types  0  and  1 
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OPCODE 

HEX  DEC 

MNEMONIC 

A  DDR, 

_ USED _ 

OPERATION 

Type  0:  ! 

Reoister  and 

transfer 

00 

0 

unused 

01 

1 

AC  CLEAR 

AC»0 

02 

2 

XR  CLEAR 

XR*0 

02 

3 

AC  INCREMENT 

AC*AC+1 

04 

4 

XR  INCREMENT 

XR*  XR+ 1 

05 

5 

XR-AC 

XR“AC 

06 

6 

AC*XR 

AC*XR 

07 

7 

AC  LOAD 

A2 

AC-PM(L2) 

08 

8 

AC  STORE 

A2 

PM(L2)«AC 

09 

9 

XR  LOAD 

42 

XR*PM(L2) 

OA 

10 

XR  STORE 

A2 

PM(L2)*XR 

OB 

11 

MOVE 

A2,A1 

PM(L2)‘PM(L1) 

oc 

12 

BACK  MOVE 

A2,A1 

PM(L1 )*°M(L2) 

00 

13 

unused 

OE 

14 

unused 

OF 

15 

unused 

' 

Type  1: 

Arithmetic, 

logical  and  branching 

10 

16 

ADD 

A2,A1 

PM(L2)**PM(L2)+PM(L1 ) 

11 

17 

SUBTRACT 

A2.A1 

PM(12)»PM(L2)-PM{L1) 

12 

18 

MULTIPLY 

A2,A1 

PM(L2)»FM(l2)*PM(L1 ) 

13 

19 

DIVIDE 

A2.A1 

PM(L2)°PM(L2)*PM(L1 ) 

14 

20 

AMD 

A2.A1 

PM(L2)iPM(L2)APM(l  1 ) 

15 

21 

OR 

A?,  A! 

PP{L2)*PM( L2  )VPM { 1 1) 

7  - 


OPCODE 

HEX  DEC 

MNEMONIC 

ADDR. 

USED 

OPE  RAT  I  Oil 

16 

22 

COMPl  EOF  N’T 

A2.A1 

PM{  L2 ) -W(Ll>-PM  (Ll )- 1 

17 

23 

unused 

18 

24 

no  to 

A2 

PC*=V2 

19 

25 

IF  >0  GO  TO 

A23A1 

If  PM(|.:?)>0:  PC«V! 

1A 

26 

IF  *0  GO  TO 

A2.A1 

If  PM(L2)*0:  PC*Y1 

IB 

27 

IF  <0  GO  TO 

A2.A1 

If  PM(L2)<0:  PC** VI 

1C 

28 

IF  <*0  GO  10 

A2.A1 

If  PM(L:?)oO:  PC'* VI 

ID 

29 

IF  >=0  GO  TO 

A2»A1 

If  PM(L?)>*0:  PC«*V1 

IE 

30 

LOOP 

A2,A1 

XR-XR+1 ;  If  XR<PH(L2):  PC-V1 

IF 

31 

CALL 

A2 

PM(L2)*PC  (store  return  ddress) 
PCV2+I 

Type  2: 

Input-output 

20 

32 

HALT 

HIT"  1  (tei-ml  nates  exccut  on) 

21 

33 

to 

unused 

2F 

47 

s 

Type  3: 

Operating  systems  support 
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unused 
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COS -Model  2 


REFERENCE  MANUAL 
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'.OS-  is  an  ex tv rs Ion  •  COS-1;  it  h  ■•n  designed  to  support  the  Triple- 

COS -2  Is  fully  iowiwai  co  ettb 
to  ru  ■  •  :  01  It  €  I n<|  i 

•o«-'.  dfc-v:t>|y  .<  jt  of  COS-1.  .  i ;  r»rstb1e  ue  to  tlx  following 

iddi  i  font's  feafcu-  «s; 

Peripheral  devices  (card  reader,  .  e  printer,  d.-uw  system,  timers) 
Interrupt  system 
Systsfl  and  user  mode 
State  pointer  rerrister 

i»-  ::i  v>\  . ,  >  -nd  operating  system  support  instructions 

t ■ . :>  i.,anu.J. f  coni 1 1  .-feme  t  Ion  about  .he  additional  features  not  Incor- 
M-  fed  U>  OS-i.  For  a  description  of  (he  basic  mode!  see  the  reference 

ami'l  for  C0S-Mode1  1. 


?_  ARCHITECTURE 

hi  uchltecture  of  CCv  has  been  enhanced  by  a  card  ruder.  *  line  print  - 
;sr,  d  drum  systwr  (con, i sting  of  a  drum  controller  amf's  3run  whTc^  c-ovTJes 
?to'  ge  for  lo  pivjcs  or  ?’<  words),  aiitf  four  CPU  iregl s ber  sTF iqure  1). 


drum  con- 
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Figure  1:  The  COS-2 
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The  four  additional  registers  serve  the  follovnnq  functions: 

The  state  pointer  register  ($P)  contains  a  physical  address  nointina  to 
the  process  state  record  of  the  currently  execution  pr  cess,  'inly  the 
eleven  least  significant  bits  of  this  32-bit  register  are  relevant. 

The  bit  positions  in  the  interrupt  and  trap  register  ( IT)  represent  pri¬ 
ority  interrupt  levels.  Bit  0  is  not  used.  Priorities  decrease  from 
level  i  to  level  31.  Currently,  only  levels  1,  2,  and  3  are  assigned  to 
traps,  the  drum  controller,  and  the  real  time  clock  (timer)  respectively. 
Bit  positions  4  through  31  are  therefore  irrelevant.  When  a  bit  is  set, 
it  indicates  that  an  event  has  occurred,  out  has  not  been  serviced  yet. 

priority  Interrupt  level 

bit  1:  TRB1T  “  2**30 
bit  2:  BCBIT  *  2**29 
bit  3:  RTBIT  *  2**28 

Interrupt  levels  must  be  armed  in  the  :ir<ivi ng  register  (AR)  if  the  corre¬ 
sponding  events  sre  to  be  serviced.  This  can  be  done  bv  selectively  set¬ 
ting  the  appropriate  bits.  A  level  is  disarmed  bv  resetting  its  bit. 

The  entire  interrupt  system  can  be  disabled  by  resetting  bit  0,  the 
enable/disable  bit.  An  interrupt  wi^l  be  serviced  only  if  the  svstem  is 
enabled,  its  leyel  is  armed,  and  no  interuunts  of  higher  priority  are 
pending. 

The  mode  register  (MD)  serves  two  functions.  Bit  0  indicates  the  mode  in 
which  tfie~CP0  is  "currently  operating;  if  it  is  set,  it  indicates  user  mode 
otherwise  system  mode.  The  remaining  bits  correspond  to  interrupt  levels. 
If  one  of  these  bits  is  set,  it  means  that  the  interrupt  routine  of  the 
corresponding  level  is  currently  running.  For  example,  when  the  drum  Inter 
rupt  routine  (a  system  process)  runs,  only  bit  2  will  be  set  in  MO. 


0  1  2  3  4  31 


3  CARD  READER 


The  card  reader  contains  a  hopper  which  is  filled  with  the  decks  of  a  num¬ 
ber  of  .jobs.  Each  deck  consists  of  a  JOB  card,  followed  by  program  cards, 
a  DATA  C3rd  and  input  data  cards  (optional),  and  an  END  card.  The  Informa¬ 
tion  on  a  card  is  encoded  in  32  bits  and  corresnonds  tn  one  machine  word. 
Special  cards  are  used  for  control  cards.  The  execution  of  a  READ  CARD  in¬ 
struction  causes  the  next  card  in  the  hopper  to  be  read  into  the  accumula¬ 
tor  AC.  In  addition,  the  card  reader  senses  the  tvne  of  a  card  (or  the 
lack  of  one)  and  communicates  it  to  a  program  bv  the  number  of  skips  which 
tiie  READ  CARO  instruction  performs: 


JOB  card 
DATA  card 
END  card 
empty  hopper 

program  or  input  data  card 


no  skip 
one  skio 
two  skips 
three  si; ins 
four  skips 


The  card  reader  also  serves  as  the  device  via  .huh  stenda^onr  •  -o 

a  •  >  car:  be  to-.  :  *•  ; 


i he  I ■  ne  t  3  ilva  via  tv  instruct!  execul  loi  ol 

a  i»r in)  LINE  Instruction,  the  contents  of  the  accumulator  AC  are  t»*  inted 
out  as  an  eight-d1<  vexadecii  ..  integet  aft*  th  Jl  aper  h 

advanced  one  line.  Thus ,  printout  *111  typically  consist  of  a  sinqle  col¬ 
umn  of  eight  la-.-iaHoruviT  digits. 

The  HEADER  ins  ion  uses  <1  •  /  •  xbi  ict  Format  nils  Instruction  Is  meant 
to  print  the  header  preceding  the  output  of  a  user  job.  Apart  from  the  job 
number,  the  header  contains  jot  statistics  (e.4>  use  of  resources)  and  pos¬ 
sibly  indications  of  an  abnoras  termination. 


5  Di.UM  SYSTEM 

The  drum  system  p»  ivldes  CIS*  ?  ith  *  >nd  y  toi  device,  Th*  ■ 
age  capacity  is  16  pages  v  128  words  each.  Drum  pages  are  addressed  bv 
their  pag*  i , e .  f*dm  0  thr<  15.  Transfers  between  the  drum  and 

primary  memory  a  on  a  /aqe  basis  in  the  sense  that  each  transferred  block 
will  consist  of  128  word*.  But  hile  a  block  must  start  on  a  pace  boundary 
or  the  drum,  ii  may  st&*t  at  any  location  In  primary  memory.  Durina  the 
time  of  the  transfer,  lie  CPU  may  execute  instructions  in  parallel. 

The  drum  controller  squires  three  parameters  for  the  supervision  of  any 
particular  transfer: 

■p-j  drum  ed  •  ss  (a  drum  j  number) 

mr  primary  ternary  addre;-  (a  physical  PM  add*-. 

direct >  (road  fra-  •  -jt.  or  write  onto  drum) 

These  three  perimeters  are  passed  to  i.h*:  drum  controller  in  a  record  (a 
drum  transfer  ncord  or  OTR;  which  is  pointed  to  by  the  contents  of  PM  lo¬ 
cation  13  or  D  in  hexadecimal.  I  ,  Illustrated  In  figure  2,  the  direction 
Is  encoded  as  ?n  integer;  a  nonpositive  Integer  spec  H  les  reading  from  the 
•drum,  a  posftffe  one  specifies  .  'iting.  The  first  and  the  fifth  words  of  a 
drum  transfer  record  art  for  use  by  the  operating  system;  they  are  iqi  ,  I 
by  thy  drum  *ontrol1er.  Vhe  name  for  the  {winter  location  and  the  dis 
placements  within  *.  drum  tram  record  are  also  given  in  Figure  ?. 


0  *  9TR$P1 

1  -  3TR$fJA 

2  *  DTRSCA 


3  **  OTR  VI  i 

4  -  OTh  ;  v> 


e  2.  '  :  T (rum  transfer  record 


V.  t  •  -  :  -  ■  ;  ;  ^  '  . 

■i'UU  •  s.  s  n  »•'  •  -fw  ■  absolute  oi-  •  leal  addresses,  v 

hi  •  :  •••»•-  .i  0  the  contents  o  tfon  D,  an  .  the  core  address  ,-i 
the  dm1  trarsfer  record. 

/*.  ■!.'  -i  involves  the  rollo*  -it:  K.tions: 

(i)  CPU  sets  op  a  drum  transfer  i  rd  and  upd*  es  location  D  to 
poir.t  to  it. 

(?)  CPU  instructs  dry*  control  let  :o  transfer  hv  executing  a 
PfAPT  DRUM  ir*-; true t ion.  7 he  e<  i.ution  of  th- s  instruction 
causes  a  control  signal  >:o  he  sent  to  the  drum  controller. 

{3}  Aftu;  receiving  the  control  s  ici  from  the  CPU,  the  drum  con¬ 
troller  checks  the  .(rum  tram  i  record  pointed  to  by  loca¬ 
tion  D  and  proceeds  to  transfer  one  word  at  a  time. 

(4)  After  ».ransf erring  128  word  ,  he  drum  controller  Informs  the 
CPU  about.  the  completion  of  tht  transfer  via  an  interrupt. 

(5)  After  the  occurrence  of  the  interrupt,  the  CPU  saves  the  stats 
of  the  currently  running  process  in  the  process  state  record 
pointed  to  by  the  state  poi.te.  register  SP  (i.e.  it  “Interrupts" 
it)  and  passes  control  to  the  u»t  interrupt  process  (drum  Inter¬ 
rupt  routine).  This  is  dene  by  loading  the  :  late  of  the  drum 
interrupt  process  from  the  pry  ess  state  record  pointed  to  by 

a  fixed  location  in  primary  v  -  ary  (see  next  section).  The  drum 
interrupt  pro. ess  will  record  the  completed  transfer  end  possibly 
initiate  another  one.  Thereafi  -r  control  is  returned  to  the 
interrupted  process  by  reloading  its  saved  state. 


6  LOW  CORE 

To  facilitate  ewviunlcatlons  between  h-  rare  and  software,  t  Is  neces¬ 
sary  to  adopt  certain  conventions,  i  o  -  example,  the  pointer  to  Lhe  current 
drum  transfer  record  Is  kept  -  by  conv  Lion  •“in  location  0.  The  logic  in 
the  drum  controller  (hardware)  knot.  v  njt  this  convention,  and  any  pro* 
grew  which  initiates  t.  transfer  must  k  \cm  about  this  convention  toe  (I.e. 
the  address  0  must  be  embedded  in  the  ftware).  Memory  locations  which 
serve  this  hardwa re/sof tware  cww-unlcfc ;  ’ ons  purpose  f.»*e  traditionally 
been  assigned  low  core  addresses  to  d  fragmentation. 

On  COS-2,  low  core  locations  ire  uud  *  hardware/i-oft*'? re  com/nleations 
for  the  following  tasks:  bootstrapping  keeping  time  ciru.r  transfer  param¬ 
eter  passing,,  and  Interrupt  handling,  i  igure  3  bepic-s  the  names  end  con¬ 
tent.}  of  those  locations.  A1 !  add, esses  of  these  locations  n>  wel '  as  their 
contents  (if  they  are  pointers'  are  t  .  i  addrr<,f<‘-, . 
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process  interrupted  by  dran 

timer  Interrupt  process 

process  interrupted  by  tlner 

*  Interrupt  transfer  Vector:  this  sector  consists  of  two  pointers  for 
each  of  the  priority  Interrupt  levels  t»  2,  e»d  3  (traps,  drew,  and  timer). 
The  second  P5R  pointer  Is  used  to  ntu«  tl»a  state  ©;•  the  interrupted  (oi 
trapping)  process  for  resumption  .’it  s  Uter  time.  1  .e  first  f*S!t  pointer 
describes  which  process  is  to  be  given  control  at  this  Interrupt  level. 


All  pointers  In  this  figure  •T<,e  pby'lcai  address  rrs . 


Figure  3:  Kawer  .nd  orie  ^  of  1*  at  font 
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Location  B  is  dedicated  as  a  tf  -sr.  At  the  end  of  the  execution  of  every 
instruction  this  locution  is  Vhcrsien ted  by  one.  A  timer  interrupt  occurs 
when  the  contents  of  location  6  become  ?ero.  The  timer  is  programed  by 
putting  into  location  8  the  negative  number  of  instruction  cycles  after 
which  an  interrupt  signal  Is  desired. 


The  tlroe-of-day  clock  is  Implemented  ir>  location  C,  Like  the  timer,  this 
location  is  fncreci:  anted  by  one  * f ter  every  Instruction.  Thus,  tlme-of  day 
fs  kept  track  of  In  units  of  1nst» action  cycles.  This  location  must  never 
be  witter,  into  if  the  correct  cime  is  to  be  maintained. 


As  outlined  in  the  previous  section,  the  current  drum  transfer  record  ii 

pointed  to  by  ToctMon  D. 


Currently,  COS- 2  allows  three  ty-.es  of  traps:  memory  violation  trap:,. 
Illegal  Instruction  traps,  a.io  operating  system  calls  (OS  CALL’s).  i^en 
a  trap  occurs,  trie  hardware  wrt  eu  the  following  trap  parameter  Int:; 

location  E:  —  - 


t&ge  parameter 

memory  violation  -2 

Illegal  Instruction  -1 

OS  CALI  > tonnage  tive  OS  CALL  number 

A  pointer  tb  the  process  state  <  .  ur  of  the  Scheduling  process  is  ke  v 

in  location  F. 

The  Interrupt  tram  fee  vector  starts  at  location  10.  it  consists  of  two 
ordf  per  Yriteiffiscpi  TeveTTUhti  r a  -:.ian  the  current  throe  levels  are 
to  be  used,  additional  pairs  of  vi’dv  oust  be  reserved. 


QUEUES 

Several  COS-2  liaU^ctltM  lid  !'.»  &:'ee,s1.-ig  queues  nf  ar  arbl  v  cvy  .d,c 

of  records  of  arbitrary  length,  Fig-tire  <5  shows  the  one-%.  rd  irtual  In  je 

pointers.  A  aagatli ;  pointer  Indicates  the  last  record  or  an  empty  queue, 
it  fils©  shows  m  *  cond  words  of  records;  tarn  .  them  t 
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figure  5*  Fovttt  of  process  ..tate  rt  id  as  known  o  the  hardware. 


8  i NSTRUCJTO  \  \±\W  fQIRE 

Dr.  COS-2,  the  COS-1  instruction  set  >  ts  tier*  enhan  id  *■>  a  mafcer  cf 
input-output  (type  2}  end  operating  -/items  support  (type  3}  Instructions. 

Some  of  there  instructions  a-e  ru  t  for  use  by  the  operatlnn  system; 
their  execution  <n  user  mode  w-V  ;  .ve  an  illeqal  ns t ruction  trao.  In 
the  following  Vs  ting,  these  i«st»  ■.*  Mo.-s  are  marked  with  an  asterisk  {  ). 
The  OS  CALI.  Instruction,  on  the  ul  ie  hard,  may  oniy  ho  executed  in  user 
node;  it  will  crap  in  system  .rode  an  is  marked  with  a  double  asterisk  (*»). 

As  on  COS-1,  At  and  «2  refer  to  aodre- s  fields,  Vi  «v:d  V2  denote  virtual 
effective  addresses,  and  LI  and  12  a.,  the  physic*,  effective  addre-ses. 

A  queue  will  he  named  after  the  addre  s  hie 'id  which  refers  to  its  heed: 
eg.  queue  A?. 
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prints  on  line  prlntr-  tor  header 
of  the  job  whose  PSK  .s  pointed 
to  by  PM(L2) 
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START  DRUM* 

Starts  drum  controller 
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Other^i  ,  ft  removes  the  1 list 
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It  removes  from  queue  A!  the  ;ecor:i 
pointed  to  by  XR,  links  It  es  the 
first  record  on  queue  A2  and  skips. 
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Inserts  ecord  pointed  to  by  XR  In 
queue  A?  before  the  first  > ecord 
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second  w  rd  o  the  Inserted  record 
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1  I MTRODUCT I ON 

The  desioners  of  a  new  computer  system  usually  avail  themselves  of  an 
operational  computer  system  (the  host  s vs ten,  or  slmnlv  host)  for  simu¬ 
lation  purposes.  Both  the  hardware  and  the  oneratino  system  are  usually 
simulated  on  this  host.  The  hardware  simulator  mav  he  written  in  anv 
suitable  lanauane  available  on  the  host;  the  proposed  operation  system 
will  tvoically  be  written  In  a  nrooramminn  lanauane  which  is  expected  to 
be  supported  on  the  new  system.  Assumlno  that  the  machine  lannuaoes  of 
the  new  system  and  the  host  differ,  none  of  the  lannuaoe  translators  on 
the  host  can  be  used  to  oenerate  code  for  the  new  noeratinn  svsten.  Thus, 
it  will  be  necessary  to  write  a  new  translator  which  runs  on  the  host  and 
translates  the  pronrammino  lannuaoe  In  which  the  new  ooeratinn  svstem  Is 
to  be  written  Into  the  new  system's  machine  lannuaoe.  Mnce  this  machine 
language  cannot  be  executed  on  the  host,  such  a  translator  Is  called  a 
cross translator.  However,  the  execution  of  code  oenerated  bv  the  cross- 
translator  can  easily  be  simulated  bv  the  hardware  simulator  runninn  on 
the  host. 

When  the  new  operatino  svstem  has  been  coded  un.  It  will  be  crossassemhled 
and  loaded  into  the  hardware  simulator  for  debunqinn.  After  the  raior  de- 
sinn  flaws  have  been  Ironed  out,  the  prototype  hardware  will  he  implemented. 
Thereafter,  It  remains  to  load  the  new  operatino  system,  which  exists  as  a 
file  In  the  host.  Into  the  orototyoe  system.  This  can  he  accomplished  bv 
crossassonblino  it  and  storlno  the  machine  lannuaoe  code  on  some  transfer¬ 
able  medium  (punched  cards,  maonetlc  tape,  disk  oack,  etc.).  This  medium 
can  now  be  moved  from  an  I/O  device  of  the  host  to  an  I/n  device  of  the 
prototype  system.  From  there,  the  oneratino  svstem  can  be  bootstraoned 
into  the  new  system. 

The  IBM  370/168-158  complex  serves  as  the  host  for  the  COS  development  pro¬ 
ject.  In  addition  to  the  hardware  simulator,  a  two-oass  crossasser.bler  for 
COS  Assembly  language  (CAL)  has  been  developed  on  the  host.  Its  outnut, 

GO'S  machine  '!  a  nonane,  can  be  loaded  Into  the  simulator  (l.e.  the  orlmarv 
memory  of  the  simulator)  from  the  driver  which  represents  the  console. 

The  other  mode  of  operation,  namely  nunchinn  oblect  code  on  cards  on  the 
host,  transferrino  them  to  th°  hooper  of  the  COS  card  reader,  and  boots - 
trapplno  from  there,  can  also  be  simulated,  a  subroutine  nackaoe  ,  which 
combines  the  Cross  Assembler  and  the  card  Reader  for  Object  Lannuaoe  (CA^OL) , 
has  been  made  available  on  the  host  for  this  nurnose.  CALlino  rApty.  will 
yield  the  next  object  lanauane  card  from  the  card  reader.  Finure  1  illustrates. 


symbolic 


CAL  proorams 


COS  cross 
assembler 


- 1 

CALL  CAROtf  Wf), TYPF, LIST) 


Figure  1:  Components  and  operation  of  the  subroutine  packaoe  CAROL. 


Internally,  CAROL  maintains  a  data  structure  for  oMect  code.  This  structure 
corresponds  to  the  hooper.  Whenever  this  data  structure  becomes  emntv,  th® 
COS  cross  assembler  is  called  and  will  fill  It  with  the  ohiect  code  and  the 
input  data  of  the  next  syntactically  correct  lob  (svntacticallv  erroneous 
jobs  are  flushed).  When  ca.led,  fADOL(’*jnRn, TYPE, LIST)  returns  the  value  and 
the  tyne  of  the  next  card  In  the  locations  specified  by  '.-/PRO  and  TYPE  re¬ 
spectively.  The  third  parameter,  LIST,  Is  an  inout  parameter  which  is  passed 
on  to  the  COS  crossassembler;  it  specifies  listinn  notions.  The  followino 
options  are  available: 

LIST  listlnos 

0  none 

1  nrooram  and  data 

2  prooram  and  data,  svmbol  table 

3  nrooram  and  data,  symbol  table,  obiect  code, 

and  data  values 

In  order  to  distinguish  assembler  llstlnqs  from  other  printout  oenerated  by 
the  hardware  simulator,  the  crossassembler  nrecedes  and  trails  all  listlnos 
with  lines  of  pi  us  signs. 


2  COS  ASSEMBLY  LANGUAGE 

A  job  written  In  CAL  Is  a  collection  of  statements  which  represent  COS 
macL.ne  instructions,  control  Instructions,  nseudo  instructions,  and  data. 
One  statement  Is  written  per  line  or,  eoulvalentlv,  punched  ner  card. 

The  languaae  Is  blank- Insensitive  and  mav  bp  coded  in  free  format.  nnart. 
from  the  pseudo  instructions,  every  statement  causes  the  Generation  of 
one  machine  word. 

Typical  statements  consist  of  an  optional  label,  a  mnemonic,  and  ontlonal 
operands  followed  by  a  semicolon.  Labels  are  terminated  hv  a  colon,  and 
operands  are  separated  by  a  comma  and  enclosed  In  parentheses.  The  first 
operand  may  be  subjected  to  Indexinn  and  Indirection;  this  is  indicated 
by  the  postfix  es  .X  or  .1  or  .I.X  for  both.  Comments  mav  be  written  after 
the  semicolon  or  on  lines  beolnnlno  with  an  asterisk.  Valid  names  ar® 
sequences  of  up  to  8  characters  tdhldi  do  not  b®o1n  with  a  sinole 
quote.  A  sinole  auote  Indicates  a  hexadecimal  constant  (all  constants  are 
hexadeclnal) .  Input  data  are  constants  followed  bv  a  semicolon  and  possible 
a  comment. 

For  most  purposes,  the  Informal  description  of  the  nrecedino  naraoranh  and 
the  example  in  chapter  4  will  suffice  to  characterize  CAL.  However,  some¬ 
times  a  more  formal  definition  Is  needed.  A  varletv  of  metalannuaoes  have 
been  developed  to  aid  In  formally  deflnlno  the  syntax  of  a  orooranmlna 
lanquaqe.  Amcnq  them,  the  Backus  Normal  Ppm  (BNF)  has  obtained  widespread 
use.  The  next  chanter  presents  a  description  of  the  CAl.  svntax  In  R*'F. 


3  BMF  FOR  CAL  SYNTAX 


The  followino  symbols  reoresent  the  elements  of  the  metalanouaoe  8”c: 

//  These  metasymbols  are  used  as  delimiters  to  enclose  the  nanr  f 
a  class. 

This  metasvmbol  may  be  read  as  "is  defined  as"  or  "consists  of". 

!  This  metasvmbol  Is  read  as  "or".  It  senarates  alternatives. 

[]  These  metasvmbol s  surround  ontlonal  classes.  If  thenemnty  class 

Is  termed  MIL,  [  /name/  ]  is  eoulvalent  to  /name/  1  K|IL. 

Names  of  classes  are  self-explanatory.  Thus,  comments  are  tent  to  a  minimum. 


/job  sequence/  /lob/  !  /job  sentence/  /job/ 

/job/  /job  stmt/  /nrooram/  [  /data  stmt./  /data/  ]  /end  stmt/ 

/prooram/  /stmt/  1  /prooram/  /stmt/ 

/data/  /datum/  !  /data/  /datum/ 

/job  stmt/  .10B  (  /const/  )  ;  [  /comment/  1 

/const/  defines  the  job  number  which  must  be  within  '10  and  '37. 

/data  stmt/  ::«••  DATA  ;  [  /comment/  ] 

/end  stmt/  END  [  (  /ond/  )  ]  ;  [  /comment/  ] 

In  an  /end  stmt/  /nod/  mav  soecifv  the  st.artine 

location^  default  Is  1). 


/stmt/  /cos  stmt/  !  /oseudo  stmt/ 

/cos  stmt/  [  /name/  :  ]  /mnem/  [(/ond/  [  .T  ]  T  .y  ]  [  ,  /ond/  ])];f/comment/] 

/mnem/  ary  COS  mnemonic  or  mnemonic  defined  by  /opcode  stmt/ 

All  mnemonics  mav  be  shortened  to  at  least  four  characters. 

/pseudo  stmt/  /comment  stmt/  !  /arrav  stmt/  1  /eouate  stmt/  ! 

/const  stmt/  !  /opcode  stmt/ 

/comment  stmt/  *  /comment/ 

/arrav  stmt/  [  /name/  :  ]  APPAY  (  /ood/  )  ;  [  /cement/  ] 

If  /ocd/  Is  a/name/.  It  must  have  beer  defined  In  a  nrecedlno  /stmt/. 

/eouate  stmt/  FOiJATEf  /name/  ,  /const/  )  :  F  /comment/  ] 

Assiqrs  the  value  /const/  to  /nam p/. 

/const  stmt/  [  /name/  :  ]  CONSTANT  (  /ond/  )  :  T  /comment/  ] 

/opcode  stmt/  OPCODE  (  /name/  ,  /const/  )  :  F  /r.orrent/  j 

Defines  new  /mnem/  if  /name/  Is  different  from  oxistino  /mnen/'s  and 
if  /const/  Is  an  unused  operation  code. 


5  " 


/ name/  /char  /[/char/[/char/[/char/[/char/[/char/r./char/[7char/]]]]]]] 
/char  /  any  character  except  /delm/ 

/del*/  5 

/opd/  /name/  I  /const/ 

/name/  must  he  defined  exactly  once  in  thr>  rrooram. 

/const/  ::=  *  /d1o/[/dia/[/d1a/[d1a/[d1o/[din/|ydin/f7d1o/]]]]]]] 

/dio /  ::«o:i!2!3:4:5:6!7:8:9!Ain:r:n:r:r 

/datum/  ::■  /consent  stmt/  I  /const/  ;  f  /comet  /  1 

/comment/  ::=  any  seouence  of  characters 


4  AN  EXAMPLE 


*  leoible 
A8: 

VARIABLE: 
VAR2: 
RESULT: 
START : 


ROUTINE: 


TEMPI : 
TEMP 2: 
POINTER: 

* 


JOB 

TO  START  IN 
EQUATE 
ARRAY 
CONSTANT 
CONSTANT 
ARRAY 
AC  LOAD 
XP.  LOAD 
CALL 
XR-AC: 
BACKMOVE 
HALT; 
CONSTANT 
AC  STORE 
XP  STORE 
ADD 

AC  LOAD 
00  TO 
CONSTANT 
CONSTANT 
CONSTANT 


( * 25) ;  while  FRFF  FORMAT  IS  POSSIBLE,  IT  TS  '^F 
COLUMNS  1,  12,  26  FOR  L*BFLS,  ’WP’ONTCS  A  fin  OPr^MDS. 
(N,  *  1 B ) ;  THIS  AND  THF  NEXT  STATFMPf!T  ARF  FOUT''nLENT 
n);  TO  ARRAY  ('IP);  "ALUF  nc  /»n  fs  onf. 
’FFFFFFFF):  THIS  IS  MTNHS  ONF 
'ABC) ; COMMENTS  ABOVE  LOOK  mfsSY  BFCAIISF  THEY 
'!);  ARE  NOT  ALIO'tFD. 


(VARIABLE); 

VAR2); 

[ROUTINE): 

(*0.X, RESULT); 

■0); 

TEMPI ) ; 
(TE*^); 

TEMP2 .TEMPI); 
'  POINTER); 
ROUTINE. I): 
'8); 

,'AA); 

(TEMP2); 


LOAD  AC 

AflO  XR  'fITH  0PFn''fins. 

C«Ll.  SUBROUTINE  (result  IS 
POINTED  TO  BY  AC  -  COPY) . 
orT  IT  INTO  RFS"LT. 

S«"F  ns  nponv  ( *i); 

"OVF  THE  T‘JR  PAt>n"FTFRS 
INTO  Mp»w>RY. 

ADD  THEM. 

OFT  POINTFR  To  S"m. 

RETURN  run"  S!!BROUTIMF. 
"FSERVFS  "MO  INTTTALI7FS  wfwn, 

oapbaof  in  fithfr  r«SF. 
OrMFRATES  0F"P'RM  RopTF0 


*  THIS  PROGRAM  SATTSFTFS  TPF  RFOHIRP’FNTS  of  ASSIGNMENT  PnOB!.EM  2.4 


HA!  A; 

*  negative  INTER  EPS  FROM  -1  to  -4 
'FFFFFFFF; 

'FFFFFFFE 
' FFFFFFFD 
'FFFFFFFC 


END 


(START) ; 


STARTING  LOCATION 


.  .'  .v 
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1  INTRODUCTION 


The  COS  Multiprogramming  Operating  System  (COSMOS)  Is  the  product  of  an 
integrated  design  methodology  which  emphasizes  the  functional  structure 
of  the  system  modules  as  well  as  their  implementation  in  the  most  suitable 
technology.  The  complexity  of  the  design  ami  the  coding  effort  can  be  con¬ 
siderably  reduced  by  moving  basic  operating  systems  functions  which  tradi¬ 
tionally  have  been  Implemented  in  software  into  microcode  and/or  hardware. 
In  particular,  access  functions  for  the  major  system  data  structures  and 
the  transfer  of  control  from  one  process  to  another  have  been  included  in 
the  instruction  repertoire.  The  overall  oroanization  of  C0SMfiS  is  defined 
in  terms  of  levels  of  abstraction. 

The  mode  of  operation  of  the  system  is  similar  to  Dijkstra's  "THE"  ’’ulti- 
programming  System.  Unnecessary  sophistication  has  been  sacrified  in  order 
to  keep  the  Implementation  effort  manageable.  For  the  same  reason,  C0SM0S 
processes  only  binary  information.  It  relies  on  a  crossassembler  (CAROL) 
for  symbol  manipulation. 

COSMOS  is  designed  to  run  on  a  COS-2  configuration.  This  configuration  in¬ 
cludes  a  CPU,  primary  memory,  a  drum  controller,  a  drum,  a  card  reader,  and 
a  line  printer.  Memory  is  paged.  The  CPU  features  a  priority  interrupt  sys¬ 
tem,  a  clock,  a  timer,  and  a  console.  Special  features  of  the  console  in¬ 
clude  a  breakpoint  facility  and  a  bootstrap  mechanism  which  is  couoled  with 
the  card  reader. 


2  MODE  OF  OPERATION 


COSMOS  is  brought  up  by  bootstrapping  from  the  card  reader.  After  Initiali¬ 
zation,  the  system  enters  the  stationary  mode  in  which  It  accepts  user  lobs 
from  the  card  reader  for  processing.  A  job  must  be  submitted  In  the  following 
order:  JOS  card,  program,  a  DATA  card  and  input  data  (optional),  and 
another  END  card.  Syntactically  incorrect  jobs  are  flushed  by  the  cross- 
assembler  and  thus  not  passed  on  to  the  card  reader. 

At  any  one  time,  several  jobs  may  be  in  the  system  at  various  staoes  of 
completion.  Any  one  job,  however,  will  be  processed  in  the  following  se¬ 
quence.  After  being  spooled  to  the  drum,  a  job's  nroqram  Is  loaded  into  core 
and  then  given  control  of  the  CPU.  For  Input,  the  nroqram  may  execute  an 
OS  CALL  which  will  provide  It  with  the  next  input  word  from  the  input  data 
page  on  the  drum.  Another  OS  CALL  causes  the  transfer  of  an  outnut  word  to 
the  output  data  paqe  on  the  drum.  After  termination  of  a  user  job,  its  out¬ 
put  is  printed  on  the  line  printer  tooether  with  some  statistics. 


3  COSMOS  DATA  STRUCTURES 


COSMOS  maintains  the  state  of  a  process  In  a  Process  State  Record  (PSR).  User 
PSR's  are  longer  than  system  PSR's  because  they  also  contain  spool  inn  Infor¬ 
mation  and  the  state  of  the  input  and  output  data  Daqes.  Except  for  the  PSR's 
of  the  scheduler  and  the  interrupt  processes,  all  system  and  user  PSR's  are 
chained  in  increasing  order  of  process  numbers  (decreasino  order  of  priority) 
on  the  queue  PSRQ.  Figure  1  shows  the  format  of  a  PSR  and  Its  initial  values 
for  a  spooled-in  user  process.  Figure  2  illustrates  in  detail  the  bit  alio- 
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short  ] 
system  < 


PSR 


Vs 


-1 

18 IT  +  USJOBHR 
-1 
-1 

W$STL0C 

ABIT 

-1 

-1 

-1 

-1 

-1 

-1 

-1 

-1 

-1 

0 

WSARRTM 

drum  page  number 
drum  page  number  or  -1 
drum  page  number  or  -1 
drum  paqe  number  or  -1 
drum  page  number  or  -1 
drum  page  number  or  -1 
drum  paqe  number  or  -1 
drum  page  number  or  -1 
drum  paqe  number  or  -1 
0 

WSWDCT 

drum  page  number 
0 


0  *  PSR$PT 

1  =  PSR$ST 

2  *  PSR$AC 

3  -  PSR$XR 

4  ■  PSR$PC 

5  =  PSR$MD 

6  *  PSR$R0 

7  *  PSR$R1 

8  =  PSR$R2 

9  =  PSR$R3 
A  =  PSR$R4 
B  =  PSR$R5 
C  =  PSR$R6 
D  =  PSR$R7 
E  =  PSR$CP 
F  *  PSR$I0 

10  *  PSR$AR 

11  -  PSR$P0 

12  *  PSR$P I 

13  =  PSR$P2 

14  *  PSR$P3 

15  *  PSR$P4 

16  *  PSR$P5 

17  =  PSRSP6 

18  *  PSR$P7 

19  -  PSR$0I 
1A  *  PSR$IX 
IB  *  PSR$IB 
1C  ■  PSRSDO 

10  »  PSR$0X 


pointer  field 
status  word 
accumulator  value 
index  reqister  value 
nropram  counter  value 
mode  reqister  value 


values  of  the 
relocation  renisters 


CPU  instruction  count 
I/O  transfer  count 

time  of  arrival 


drum  panes 
for  urogram 


drum  innut  paqe 
drum  input  pane  index  * 
drum  input  pane  bound  ** 
drum  output  Dane 
drum  outnut  paqo  index  * 


*  displacement  of  next  access;  **  total  number  of  input  data  words 


Figure  1:  Format  of  a  Process  State  Record  and  its  initial  values. 


0  1 

2 

3 

4 

5  6 

7 

18 

19 

20 

21 

22 

23 

24  31 

A  B 

L 

T 

P 

I  0 

X 

V 

U 

Q 

N 

F 

process  § 

PSR$ 


Scheduling  bits: 

A  active 
8  blocked 
L  to  be  loaded 
T  to  be  terminated 
P  to  be  printed 
I  input 
0  output 


Abnormal  termination  bits: 

V  memory  violation 
U  illegal  inst. uctlon  in  user  mode 
o  quantum  overflow 
N  no  more  words  in  input  Dage 
F  full  output  paqe 


Figure  2:  Bit  allocation  in  a  PSR  status  wo-d. 


0  =  DTR$PT 

1  «=  DTR$DA 

2  *  DTR$CA 

3  ■  DTR$RW 

4  ■  DTR$SP 


pointer  field 
drum  naoe  number 
physical  core  address 
read/write  specification 
pointer  to  PSR  of  reauestina 
process 


Read/write  specification: 

DTR$RW  specifi cation 

<0  read  from  drum  to  core 

>0  write  from  core  to  drum 


-2  read  requested  by  system  process 

-1  read  drum  input  page  of  user  process 

0  read  drum  output  page  of  user  process 

1  write  drum  output  page  of  user  process 

2  write  requested  by  system  process 


Figure  3:  Format  and  encoding  of  a  Drum  Transfer  Record. 


0123  29  30  31  bit  and  page  number 


The  status  of  a  particular  page  is  indicated  by  its  corresponding  bit: 

a  zero  bit  indicates  an  allocated  or  non-existing  page, 
a  one  bit  Indicates  an  available,  unallocated  page. 


Figure  4:  Format  and  encoding  of  an  allocation  word. 


cation  of  the  status  word  iri  a  PSR. 


Drum  processes  are  described  by  Drum  Transfer  Records  (DTR's)  which  are 
chained  on  the  drum  queue  LC$DR0  and  serviced  In  FIFO  fashion.  In  addition 
to  the  three  DTR  entries  required  by  the  drum  controller,  COSMOS  uses  the 
first  word  as  a  queue  linkaqe  nointer  and  the  last  word  as  a  nointer  to  the 
PSR  of  the  process  requesting  the  transfer.  Figure  3  Illustrates. 

With  the  exception  of  Its  own  code,  which  Is  core-resident,  COSMOS  allocates 
all  core  and  drem  storage  dynamically  on  a  page  basis.  Figure  4  depicts  the 
format  and  the  encoding  of  the  two  words  which  are  used  to  keen  track  of  the 
allocation  state  of  core  and  drum  pages. 


4  COSMOS  STRUCTURE 


Two  global  functions  of  an  operating  system  concern  the  efficient  management 
of  the  hardware  components  and  the  provision  of  a  convenient  interface  to 
the  users  of  a  computer  system.  According  to  this  rounh  classification,  the 
COSMOS  modules  may  be  separated  Into  user  support  modules  and  hardware 
support  modules. 


The  choice  of  the  functional  modules  for  user  support  Is,  of  course,  stronqlv 
influenced  by  the  desired  mode  of  operation.  For  COSMOS,  the  following 
functional  modules  evolved  and  have  been  Implemented  as  processes: 


Function: 

Input  spooling 

Loading 

Input/output 

Termination 

Printing 

Scheduling 


Process  name: 

RCARD  and  WCARD 

LOADER 

FILE  SYSTEM 

TERMINATOR 

PRINT 

SCHEDULER 


Input  spooling  makes  use  of  double-buffering  and  conseouently  two  processes 
evolved  for  Its  Implementation.  Except  for  the  SCHEDULER,  all  of  the  processes 
named  above  as  well  as  user  processes  are  given  control  of  the  CPU  by  the 
SCHEDULER;  the  term  schedulable  processes  refers  to  this  set  of  processes. 


Since  the  concept  of  a  process  is  not  known  to  the  bare  hardware,  not  all 
hardware  support  modules  can  be  implemented  as  processes.  In  fact,  three 
different  module  types  have  been  adopted:  processes,  subroutines,  and  In¬ 
structions.  The  different  technologies  of  these  types  are  a  consenuence 
of  the  integrated  design  methodology  adopted  for  COSMOS.  It  should  be 
pointed  out  In  this  context  that  the  tern  hardware  support  has  a  dual  meaning. 
It  may  refer  to  the  support  of  hardware  components,  but  It  may  also  mean 
support  of  the  operating  system  by  a  hardware  function.  The  maior  hardware 
support  modules  are  listed  below. 


Function: 


Module  name  and  tyne: 


Service  of  timer  interrupts 
Service  of  drum  interrupts 
Service  of  traps 

Service  of  drum  transfer  requests 
Accessing  of  PS.R's  and  DTR's 
Page  allocation 


Timer  Interrupt  Process 
Orur.i  Interrupt  Process 
Tran  Process 

Shared  Subroutine  PUTDRQ 

Queue  Instructions,  STITCH  PROCESS  Instr. 

Allocation  instructions 


The  three  module  types  form  a  technological  hierarchy  since  a  process  may 
contain  several  subroutines  and  since  a  subroutine  typically  consists  of 
several  instructions.  In  addition.,  the  modules  themselves  form  a  functional 
hierarchy  due  to  the  nature  of  their  operations.  The  term  levels  of 
abstractions  refers  to  this  functional  hierarchy. 

It  was  pointed  out  that  operating  systems  have  two  interfaces:  to  the  hardware 
and  to  the  users.  In  a  way,  an  operating  system  "maps"  the  hardware  components 
such  that  they  appear  more  convenient  to  the  user.  For  instance,  a  user  pro¬ 
gram  may  reference  a  file  by  a  symbolic  name.  Internally,  the  operating  s'/stem 
will  map  this  name  into  a  file  number  which  is  mapped  into  a  buffer  which  is 
mapped  into  a  drum  page.  Clearly,  those  modules  of  an  operating  svstem  which 
relate  to  files  are  organized  in  levels  such  that  hiqher  level  modules  are 
defined  and  implemented  in  terms  of  lower  level  modules.  This  is  not  onlv 
true  for  the  concept  of  a  file,  but  for  all  virtual  concents  (e.o.  virtual 
memory,  operating  system  calls)  provided  by  an  operating  system.  While  the 
existence  of  such  levels  of  abstractions  is  obvious,  it  is  often  nulte 
difficult  to  draw  the  dividing  lines  between  them.  This  task  is  difficult 
because  it  requires  a  thorough  understanding  of  all  system  aspects.  Con¬ 
sidering  the  size  of  contemporary  operatino  svstems,  such  a  comolete  under¬ 
standing  is  often  impossible  for  any  single  Individual.  A  number  of  basic 
criteria  aid  in  the  definition  of  these  levels: 

.a  module  must  not  be  defined  In  terms  of  a  higher  level  module 
.a  data  structure  and  Its  access  modules  should  be  in  the  same  level 
.a  leva!  should  Implement  a  concept,  i.e.  nrovlde  an  abstraction  to 
tht*h1gher  levels 

Figure  5  displays  the  levels  of  abstraction  adopted  for  COSMOS. 

Control  may  be  transferred  between  processes  by  either  of  two  mechanisms: 
the  SWITCH  PROCESS  Instruction  and  the  interrupt  mechanism.  The  latter  serves 
to  forcefully  transfer  control  to  an  interrupt  process.  The  SWITCH  PROCESS 
instruction  Is  used  by  the  SCHEDULER  to  transfer  control  to  a  readv  process. 
All  other  user  support  processes  as  well  as  the  Trap  Process  and  the  Timer 
Interrupt  Process  use  it  to  return  to  the  SCHEDULER.  Finally,  the  Drum  Inter¬ 
rupt  Process  uses  it  to  return  to  the  interrupted  process.  The  SCHEDULER  has 
no  knowledge  of  the  function  of  the  process  it  is  giving  control  to;  all  It 
checks  is  whether  a  process  is  ready  (active  and  unblocked)  to  run.  It  is  the 
responsibility  of  the  other  system  processes  to  maintain  the  scheduling  bits 
of  all  schedulable  processes.  Typically,  a  process  will  activate  another  one 
when  it  has  evidence  that  the  other  process  has  work  to  do.  At  the  same  tine 
an  indication  must  be  given  as  to  what  ouantitv  (e.g.  a  user  process)  the 
other  process  should  work  on.  A  process  is  deactivated  by  another  ore cess  or 
by  itself  when  it  is  evident  that  no  more  productive  work  can  be  done. 


COSMOS  SOFTWARE 


The  COSMOS  softv/are  consists  of  the  code  of  the  ten  sister;  processes  and 
the  subroutine  PUTDRO.  In  order  to  reflect  the  system  structure  in  the  code,, 
naming  conventions  for  variables  and  labels  have  boen  ndonted.  All  names  of 
local  quantities  are  prefixed  with  characters  indicatinn  the  module  to  which 
they  belong.  Thus,  names  of  shared  alobal  ouantities  are  characterized  by 
the  lack  of  a  prefix.  Further  particulars  of  a  process  module  include  a  pro¬ 
cess  number,  a  range  of  PUNT  numbers,  and  a  global  variable  containino  its 
PSR  address.  The  particulars  of  the  various  process  modules  are  summarized 
below: 


pref  1  x  groc.  ji  PUNT  #'s  PSR  ptr. 

Non-schedulable  Processes: 


SCHEDULER 

S$ 

'0 

'lO-’lF 

LC$SCH 

Trap  Process 

TR$ 

'0 

' 20- '2F 

LCSTPP 

Drum  Interrupt  Process 

DI$ 

'0 

'  30- *  3F 

LC$DIP 

Timer  Interrupt  Process 

T I  $ 

*0 

'40-'4F 

LC$TIP 

Schedulable  Processes: 

RCARD 

R$ 

1 8B 

' 50- ' 5F 

ADPSRf’ 

WCARD 

w$ 

*39 

’60-'6F 

ADPSRW 

(shared  sooollnq  variables) 

RU$ 

i OADER 

L$ 

'87 

‘70-'7F 

ADPSRL 

FILE  SYSTEM 

F$ 

‘85 

•so-'aF 

ADPSRF 

TERMINATOR 

T$ 

'  5 

:90-'9F 

'TIPSRT 

PRINT 

PS 

'7 

'A0- 1 AF 

APPSnP 

Initially,  the  PSR's  of  the  schedulable  system  processes  are  chained  on  the 
PSR  queue  PSRQ  in  increasino  order  of  their  process  numbers,  or  eouivalentlv 
in  decreasing  order  of  priority  (the  enuivalence  is  due  to  the  simple  sched¬ 
uling  strategy  adopted  for  the  SCHEDULER  which  scans  the  PS^  oueue  until  It 
finds  the  first  process  ready  to  run). 


5.1  SCHEDULER 


The  scheduler  serves  two  functions:  dynamic  initialization  of  the  system 
and  scheduling.  The  initialization  senuence  is  aiyen  control  from  the  boots¬ 
trap  loader  and  involves  completing  the  bootstrap  operation  and  the  proper 
setting  of  the  CPU  registers. 

The  schedu.ing  sequence  attempts  to  find  a  readv  process  in  th<-  PSR  oueue 
and  pass  control  to  it  after  sottino  the  timer  to  prevent  infinite  loenlno. 
If  no  ready  process  is  found,  the  scheduler  makes  sure  that  there  are  still 
active  processes  In  the  PSR  queue  and  branches  back  to  the  beqinninn  of  the 
scheduling  sequence.  When  all  processes  are  deactivated,  the  batch  of  user 
jobs  submitted  to  COSMOS  must  have  been  serviced  to  completion  and  the 
scheduler  HALTs. 


Code  for  SCHEDULER: 


*  SCHEDULER  * 

A*************************************'*;****************************  ******* 


INITIALIZATION  {GETS  CONTROL  FROM  BOOTSTRAP  LOADER) 


S$II1IT : 


XR  LOAD 
SP=XR; 

IT  RESET 
AR  RESET 
AR  SET 
AC  LOAD 


(LC$SCH); 

(5IEGOHE) ; 
(NEGONE) ; 
(INTBITS) ; 
(ABIT); 


INITIALIZE  SP 
CLEAR  IT 
CLEAR  AR 

ENABLE  AND  ART  LEVELS 
PUT  PATTERN  FOR  MATCHING 


SCHEDULING 


S $ENTRY :  MOVE  (LC$RTC,  SSOUANT); 

FIND  RECORD  (PSRO,  ABB  ITS); 
GOTO  (SSACHECK); 

SWITCH  PROCESS  (S SENTRY) ; 


SET  TIMER 

FIND  READY  PROCESS 
NO  PROCESSES  READY 
PASS  CONTROL  TO  READY  PPOC 


CHECK  FOR  BATCH  COMPLETION 


SSACHECK:  FIND  RECORD  (PSRQ,  ABIT);  FIND  AN  ACTIVE  PROCESS 

HALT;  NONE,  BATCH  COMPLETED 

GOTO  (SSENTRY);  OBVIOUSLY  BLOCKED,  KEEP 

*  SCANNING  PSRO  WHILE  WAITING  FOR  ANY 

*  PROCESS  TO  BECOME  READY 
************************************************************************* 

*  LOCAL  VARIABLES 


FIND  RECORD 
HALT; 

GOTO 


(PSRQ,  ABIT); 


SSQUANT:  CONSTANT  ( ' FFFFEFFF) ;  LARGE  NEGATIVE  QUANTUM 

************************************************************> ************ 


The  shared  subroutine  PUTDRQ  serves  as  the  central  mechanism  for  submittino 
I/O  requests  to  the  drum  system.  When  called,  PUTDRQ  expects  in  AC  a  pointer 
to  a  5-word  I/O  parameter  table  whose  format  is  identical  to  a  RTR.  It 
copies  the  I/O  parameter  table  into  a  DTR  which  it  obtains  from  the  freelist 
appends  the  DTR  to  the  drum  queue  LC$DRQ,  starts  the  drum  if  and  onlv  If  the 
drum  queue  was  empty,  and  returns  by  skipninq.  A  no-skip  failure  return  indi 
cates  that  currently  there  are  no  DTR’s  available  on  the  freelist. 


-  :U 


Code  for  PUTDRQ : 


i  !■»**********■*********■<!-?;*  Jrklt  A-  *  &Yr*****  A****************************-*** 


4-  SHARED  SUBROUTINE  PUTDRQ  * 


PUTDRQ : 

ARRAY 

XR  STORE 

AC  STORE 
GET  RECORD 
GO  TO 

XR  STORE 

XR  LOAD 

XFER: 

W 

AC  LOAD 

AC  STORE 
LOOP 

*1); 

(XRSAVE); 
(ACTABLE) ; 
(DTRFRLS) ; 
(PUTDRQ.  I); 
(ADDTR); 

(ONE); 

(ADTABLE. I  .X>  *, 
(ADDTR. I. X); 
(DTRSIZE ,  XFER); 


FOR  RETURN  ADDRESS 


FAILURE  RETURN 
DTR  ADDRESS 


*  START  DRUM  CONDITIONALLY 

* 


XR  LOAD 
AR  RESET 

it 

APPEND  RECORD 
IF  <0  GO  TO 
START  DRUM; 
RESTORE:  AR  SET 

XR  LOAD 
AC  LOAD 
ADD 
GO  TO 


(ADDTR); 

(DCBIT);  HATCH  OUT  FOR  DRUM  INTER¬ 

RUPT  PROCESS,  LC$DRO  IS  SHARED! 

(LC$DRQ); 

(LC$DRQ. I ,  RESTORE); 

(DCBIT); 

(XRSAVE); 

(ADTABLE) ; 

(PUTDRQ,  ONE);  IN  ORDER  TO  SKIP 

(PUTDRQ, I);  SUCCESS  RETURN 


*  LOCAL  VARIABLES 


XRSAVE: 

ARRAY  I 

H); 

SAVE  LOCATION 

ADTABLE : 

ARRAY  1 

■1); 

A DDR  OF  I/O  PARAMETER  TABLE 

ADDTR: 

*4**4***-*! 

ARRAY  | 

!'l); 

DTR  ADDRESS 

5.3  INPUT  SPOOLING 


A  user  Job  submitted  via  the  card  reader  is  transferred  to  the  drum  before 
it  is  loaded  for  execution.  COSMOS  employs  a  dynamic  double-buffer! no  scheme 
for  this  spooling  task.  In  this  scheme,  the  process  RCARD  may  fill  a  dynam¬ 
ically  allocated  buffer  A  concurrently  with  the  transfer  of  the  previously 
filled  buffer  B  to  the  drum.  The  transfers  are  initiated  and  terminated  bv 
the  process  WCARD  which  also  initializes  a  PSR  for  the  enterino  iob.  A  set 
of  shared  variables  prefixed  by  RU$  serves  for  communications  between  RCARD 
and  WCARD.  Via  this  set,  RCARD  informs  WCARD  about  the  address  of  the  dynam¬ 
ically  allocated  buffer  as  well  as  various  job  narameters  determined  durinu 
reading  (job  number,  starting  location,  buffer  contents:  program  or  data, 
number  of  input  words,  arrival  time). 


1 _ 


Consecutive  activations  of  RCAPD  and  WCARD  must  necessarily  concern  an 
alternating  sequence  of  the  two  buffers:  A,  B,  A,  B,  A,  B,  ...  The  current 
buffer  may  be  determined  by  local  variables  R$SWITCH  and  W$SWITCH  which 
assume  the  values  0  and  -1  (Initially  0}  and  are  flipped  after  every  In¬ 
vocation  of  the  corresponding  process.  Since  the  two  buffers  may  contain 
parts  of  two  different  user  jobs  (e.g.  the  Input  data  of  one  job  In  one 
buffer  and  the  first  program  page  of  the  next  job  In  the  other  buffer), 
the  set  of  shared  variables  prefixed  by  RW$  should  be  duplicated.  If  two 
consecutive  words  are  allocated  for  each  of  these  variables.  Indexing  with 
the  value  of  R$SWITCH  or  W$SWITCH  may  be  used  to  access  the  currently 
relevant  variable. 

The  Indexed  shared  variables  RW$TYPE  describe  the  contents  of  the  current 
buffer.  They  may  assume  the  values  -1,  0,  +1  for  input  data,  an  empty 
buffer,  and  code  respectively.  RW$LAST  Indicates  whether  the  current 
buffer  Is  the  last  one  of  a  job  (RW$LAST«1)  or  not  (RW$LAST*0). 

Another  shared  variable  RW$NRBF  Indicates  the  number  of  buffers  (0,  1,  2) 
currently  filled.  It  Is  used  to  control  the  activations  of  the  two  spooling 
processes.  RW$NRBF  will  effectively  synchronize  the  activations  such  that 
no  more  than  two  buffers  can  be  allocated  to  Input  spooling  at  any  one  time. 
Since  the  value  of  RW$NRBF  Is  not  related  to  the  contents  of  the  buffer(s), 
RW$NRBF  need  not  be  duplicated. 


5.3.1  RCARD 


When  Invoked,  RCARD  allocates  a  new  buffer.  Thereafter,  It  loops  reading 
cards  Into  this  buffer  until  either  an  END  or  DATA  card  is  encountered, 
the  buffer  Is  completely  filled,  or  there  are  no  more  cards  In  the  hopper. 
Upon  detection  of  a  JOB  card,  RCARD  notes  the  arrival  time  (R$APRTM)  and 
the  job  number  (RJJOBNR)  and  Initializes  R$TYPE,  R$LAST,  the  wordcount  of 
the  Input  data  (R$WDCT),  and  R$PR0G.  R$PR0(?  is  set  to  zero  when  a  DATA  card 
Is  read  in  (contrary  to  the  JOB  card,  the  DATA  card  Is  not  deposited  In  the 
buffer).  Reading  an  END  card  will  cause  the  starting  location  (R$STL0C)  to 
be  noted  and.  If  Input  data  were  attached  to  the  job  (R$PR0fi«0),  their 
number  Is  also  remembered  (P$WDCT). 

A  buffer  Is  shipped  to  WCARD  when  It  is  full  or  when  an  END  or  DATA  card 
Is  detected  (a  DATA  card  arrlvlna  as  the  first  card  after  an  Invocation 
and  an  END  card  following  exactly  128  Input  data  are  treated  as  special 
cases).  Before  shipping,  the  shared  variables  prefixed  with  RW$  are  up¬ 
dated  from  local  variables  In  order  to  inform  WCARD  about  the  nature  of 
the  current  buffer.  Then  P$SWITCH  Is  flipped  and  RW$NRBF  Is  Incremented. 
Before  returning  to  the  SCHEDULER,  RCARD  deactivates  Itself  If  both  buffers 
are  filled  or  If  there  are  no  more  cards  In  the  hopper.  If  both  buffers  had 
been  empty  before  the  current  one  was  filled,  WCARD  Is  activated  to  work 
on  this  current  buffer. 


-  1 2  - 


Flowchart  for  RCARD: 


note  buffer  address  in  R$BUF ,  init.  Index  to  next  buffer  word  (XR»0) 


incr.  RW$NRBF 
R$RET 


Cede  for  RCARD : 

**********  **  ********  ****<r**-.5t****A-*  fr************^************  **  ************* 

*  RCARD  * 

****************  **********  t*****^*********  ********************************* 

R$ENTRY :  ALLOCATE  (PMWORD); 


60  TO 
XR  STORE 
MULTIPLY 
XR  CLEAR; 


(PMWORD); 

(R$RET); 


(R$BUFt  PGSZ); 


READ  AND  PROCESS  NEXT  CARD 


R$READ: 


R$JOB: 


R$RE6: 


PSDATA: 


R$EMPTY: 


P$END; 


RSWHAT: 


R$CLEAR: 


P$CLLP: 


READ  CARD; 

GO  TO 
60  TO 
GO  TO 
GO  TO 
GO  TO 
MOVE 
AC  STORE 
MOVE 
MOVE 
MOVE 
MOVE 

PUT  ABSOLUTE 

LOOP 

IF  -0 

GO  TO 

MOVE 

XR  STORE 

IF  >0 

MOVE 

GO  TO 

DIVIDE 

XR  LOAD 

DEALLOCATE 

PUNT 

XR  LOAD 

AND 

GO  TO 

AC  STORE 

MOVE 

XR  STORE 

IF  >0 

MOVE 

GO  TO 

IF  >0 

MOVE 

XR  STORE 

SUBTRACT 

IF  »0 

AC  CLEAR; 

PUT  ABSOLUTE 
LOOP 


(R$JOB); 

(R$DATA); 

«; 

Y); 

(R$REG) ; 

(R$ARRTM,  LC$TOD) ; 
RJJOBNR); 

(R$WDCT,  ZERO); 
{R$LAST,  ZERO); 
(R$TYPE,  ONE); 
(R$PROG,  ONE); 

IR$BUF.I.X); 

PGSZ,  R$READ); 
R$PROG,  R$READ); 
R$COPY); 

R$PROG ,  ZERO); 
R$XR) ; 

R$XR,  R$CLEAR) ; 
(R$TYPE,  NEGONE); 
(R$READ); 

(R$BUF,  PGSZ); 

(P$BUF); 

jPMWORD); 

iADPSRR); 

PSR$ST.X,  CABIT); 
R$RET) ; 

R$STLOC); 

R$LAST,  ONE); 
R$XR) ; 

R$XR,  R$WHAT); 

!R$TYPE,  ZERO); 
R$COPY); 

R$PR06,  R$CLEAR); 
R$TYPE ,  NEGONE); 
R$WDCT) ; 

R$XR,  PGSZ); 

R$XR,  RJCOPY); 

(R$BUF.I.X); 

(PGSZ,  R$CLLP); 


UPDATE  VARIABLES  SHARED  WITH  WCARD 


5.3.2  WCARD 

When  Invoked  to  Initiate  the  transfer  of  the  first  buffer  of  an  enterlno  user 
job,  WCARD  obtains  and  Initializes  a  PSR  for  this  user.  This  PSR  Is  updated 
during  consecutive  Invocations  until  the  complete  job  resides  on  the  drum  and 
Is  ready  to  be  loaded.  WCARD  supervises  one  buffer  transfer  per  Invocation. 

If  the  current  buffer  Is  not  empty,  a  drum  page  Is  allocated  and  Its  address 


Flowchart  for  WCARD: 


V. 


WfENTRY 

load  XR  with  buffer  switch  W)SWITCH  and  I copy  the  Indexed  shared  vari¬ 
ables  RH$BUF,  RW$U0CT,  RV$TYPf ,  RHfLAST,  RW$ARRTH,  RWSSTLOC,  RH$J0BNR 
to  the  corresponding  local  variables  prefixed  by  W$.. 


G 


get  PSR  ] 


/ 


PSR  ready  / 


no 


yes 


<succ7s?> 


note  pointer  in  U$PSRPT 
and  clear  PSR  (-Vs) 


W$CHK8 


Xe-s-<-  m$type-o 

_ L _ 

|  get  drum  page  | 

v  no 

•^success - 


<1 


note  drum  page  number  in  PSR  and  I/O  parameter  table,  cooy  card  buffer 
address  W$8tlF  Into  I/O  parameter  table  _ J 


call  PUTORQ 


success/- 


no 


'A 


block  WCAPn  j 

2*"etbi 


j  deallocate  card  buffer,  decrement  the  state  variable  RRSMBF,  fllo  thp 
buffer  switch  WSSWITCH  _ _ 


£ 

Y 


-yj5-.-<l^LAST>6> 


no 


get  drum  output  page 


no 


-<successj> 


note  page  number  in  PSR,  Initialize 
remaining  PSR  entries.  Insert  PSR 
in  PSRQ,  set  W$PSRPT  to  minus  one 


no 


WSSYNCH 
A^W$NRBF^oV?* 


|  activate  RCARDj  ^deactivate  WCARD 


s»-j 

Is 


V$RET 


Is  noted  In  the  appropriate  PSR  slot  for  the  given  program  or  Input  data 
page.  Before  calling  PUTDRQ,  this  address  and  the  buffer  address  are  In¬ 
serted  In  the  I/O  parameter  table.  Thereafter,  WCARD  blocks  Itself  and  will 
not  resume  execution  until  the  Drum  Interrupt  Process  unblocks  It  after  the 
completion  of  the  transfer.  Then,  the  buffer  Is  deallocated,  RWJNRBF  Is 
decremented,  and  RW$sw1tch  Is  flipped  to  keep  track  of  the  alternating 
buffer  sequence. 

If  the  current  buffer  Is  the  last  one  of  a  job,  the  drum  output  page  is 
allocated,  the  remalnlno  PSR  entries  are  Initialized  (Figure  1),  and  the 
LOADER  Is  activated.  Before  returning  to  the  SCHEDULER,  WCARD  activates 
RCARD  If  *oth  buffers  had  been  filled  before  the  current  transfer.  If  both 
buffers  are  empty  after  the  current  transfer,  WCARD  will  deactivate  Itself. 


5.4  QRUM  INTERRUPT  PROCESS 

After  the  occurrence  of  a  druiii  completion  Interrupt,  the  Orun  Interrupt 
Process  dtermines  from  the  current  -Y'!  whether  the  transfer  was  oriolrallv 
requested  by  a  system  process  or  a  user  process.  Jn  the  former  case,  the 
Drum  Interrunt  Process  cleans  up  after  the  transfer  bv  returning  the  cur¬ 
rent  3TR  to  the  freelist,  unblocking  and  charging  the  requesting  nrocess, 
and  -  if  the  drum  queue  is  not  enotv  -  startinn  the  drum. 

If  the  requesting  orocess  was  a  user  process,  the  brum  Interrupt  Process 
follows  up  on  the  actions  initiated  bv  the  FILF  SYSTE”.  looicallv,  thpse 
actions  do  not  belong  to  the  Orurn  Interrupt  Process,  hut  thev  are  short 
and  a  further  activation  of  the  FILE  SYSTE"  appears  cumbersopu?.  iote  this 
as  an  example  of  bad  system  desinn!  Looical  cleanliness  should  be  given 
priority  over  efficiency  considerations  unless  some  verv  convincing  arnu- 
merits  to  the  contrary  have  been  thought  through. 

On  user  Input,  the  next  input  word  is  cooled  from  the  I/O  buffer  to  the 
user's  PSR,  the  sequential  I/O  count  is  incremented,  and  the  I/o  buffer 
is  deallocated.  Thereafter,  the  Orun  Interrunt  Process  cleans  ur>  as  for 
a  transfer  reouested  by  a  system  process. 

For  user  output,  the  drum  output  pane  must  he  rpad  Into  an  I/O  buffer, 
updated,  and  written  back  to  the  drum,  '’fter  it  has  been  read,  the  >rum 
Interrupt  Process  transfers  the  output  word  from  the  PS’’,  to  the  T/o  buf¬ 
fer,  updates  the  sequential  I/O  count,  channes  the  direction  of  the  cur¬ 
rent  DTI  to  reflect  that  the  output  nane  Is  to  bp  written  back,  and  starts 
the  drum  after  charging  the  user  process  for  the  T/o  transfer.  The  next 
interrupt,  which  signals  that  the  drum  outnut  naoe  has  boon  written  back, 
is  serviced  bv  deallocating  the  I/O  buffer  and  cleaning  up  as  for  a  trans¬ 
fer  requested  bv  a  system  process. 


.*  •’  *'  w"  -■ 


Flowchart  for  Drum  Interruot  Process: 


DI SENTRY 


5. 5  TRAP  PROCESS 


The  execution  of  an  illegal  instruction,  a  memory  violation,  or  an  OS  CALL 
(READ,  WRITE,  STOP)  results  in  an  invocation  of  the  Tran  Process.  C0S"OS 
itself  should  not  cause  any  traps,  and  therefore  the  Tran  Process  PVTITs 
if  the  trappinq  process  is  a  system  nrocess.  For  user  nrocesses  trans 
represent  the  means  by  which  control  may  be  passed  had.  to  the  system 
which  will  perform  some  task  for  this  nrocess.  The  Tran  Process  essential¬ 
ly  activates  a  system  process  to  perform  this  task,  soecifles  the  nature 
of  the  task  in  the  status  word  of  the  user's  PSR,  and  returns  to  the 
SCHEDULER. 

For  READ  (WRITE),  the  scheduling  bit  IB  IT  (OBIT)  is  set  in  the  status  word, 
the  user  process  Is  blocked,  and  the  FILE  SYSTEM  is  activated  to  initiate 
the  I/O  operation. 

After  an  Illegal  Instruction  trap  or  a  memory  violation  tran,  an  abnormal 
termination  bit  is  set  in  the  status  word  of  the  user's  PSR.  Then,  the 
user  process  is  deactivated,  scheduled  for  termination,  and  the  TERMINATOR 
is  activated.  The  latter  actions  are  also  performed  when  the  user  nrocess 
simoly  STOPs  (normal  termination). 


Flowchart  for  Trap  Process: 


TR5RET 


5.6  FILE  SYSTEM 


C\i  - 


The  FILE  SYSTEM  is  activated  by  the  Trap  Process  when  a  user  process  exe¬ 
cutes  a  READ  or  a  WRITE.  Since  the  Trap  Process  also  sets  the  schedulino 
bits  IB  IT  or  OBIT,  the  FILE  SYSTEM  can  find  the  user  process  by  scanning 
the  PSR  queue.  The  FILE  SYSTEM  deactivates  itself  If  none  of  these  sched¬ 
uling  bits  are  set  in  any  of  the  schedulable  processes. 

After  the  requesting  user  process  has  been  found,  a  check  is  performed  to 
make  sure  that  the  input  data  have  not  been  exhausted  (for  PEAD)  or  that 
the  output  page  is  not  full  (WRITE).  If  such  a  condition  exists,  the 
appropriate  abnormal  termination  bit  is  set  and  the  user  nrncess  is  deac¬ 
tivated,  unblocked,  and  scheduled  for  termination. 

If  the  I/O  request  is  reasonable,  an  I/O  parameter  table  is  set  up,  an 
I/O  buffer  is  allocated,  and  the  transfer  of  the  input  or  output  pane 
is  initiated  by  calling  PUTDRQ.  Since  the  remaininn  actions  will  be  per¬ 
formed  by  the  Drum  Interrupt  Process,  the  FILE  SYSTEM  has  completed  its 
task  and  returns  to  the  SCHEDULER. 


Flowchart  for  FILE  SYSTEM 


scan  PSn  for  user  process  request! nq  output 


succes'sN  vos  'xf!  conta1ns  PSR  P° ' n ter ) 


scan  PSRQ  for  user  process  request! nq  inout  (7BIT)  ] 
- - 

yes  (XR  contains  PSR  pointer) 


reset  IB IT;  check 
for  excessive 
input: 


deactivate 
FILE  $YS7Ef 


reset  OBIT;  check 
for  excessive 
output: 


PSR$IX<PSR$IB 


note  user  input 
(direction=-l) 
anc!  drum  input 
page  (PSR$DI)  in 
I/O  parameter 
table 


set  abnormal 
termination 
bit  MBIT 


set  abnormal 
termination 
bit  FBIT 


set  termination  bit  TBIT 
reset  activation  bit  ABIT 
reset  blocked  bit  BBIT 


PSR$OX<PGSZ 


note  user  output 
(direction^) 
and  drum  output 
pane  (PSR$D0)  in 
I/O  parameter 
table 


1  note  user  PSR  pointer  (from  XR)  in  I/O  parameter  table 

|  pet  I/O 

buffer  /^\ 

__  ..  v 

5.7  LOADER 


After  a  user  job  has  been  transferred  to  tne  drum  by  the  ir.nut-spoo] inn 
system,  WCARD  schedules  the  user  process  for  loadino  and  activates  the 
LOADER.  When  invoked,  the  LOADER  finds  the  process  to  be  loaded  by  scan¬ 
ning  the  PSR  queue.  The  LOADER  deactivates  itself  when  there  are  no  more 
processes  to  be  loaded. 

COSMOS  employs  a  static  preloadinq  scheme,  i.e.  all  panes  of  a  user  process 
must  be  loaded  before  execution  may  beoin.  A  nartiallv  loaded  Process  will 
therefore  tie  up  core  naqes  without  beinn  able  to  prepress  towards  com¬ 
pletion.  In  order  to  avoid  such  an  unproductive  drain  on  an  imnortant 
system  resource,  the  LOADER  ascertains  that  there  are  enouoh  core  oaoes 
available  to  load  the  entire  program  before  it  proceeds  to  load  the  first 
program  page. 

The  LOADER  consists  of  three  major  loops.  In  the  allocation  loor>,  an 
attempt  is  made  to  allocate  all  necessary  core  panes.  If  this  attemnt 
fails,  those  pages  which  were  available  and  were  allocated  temporarily 
are  returned  to  the  freelist  iri  the  deallocation  loon.  The  LOADER  will 
then  return  to  the  SCHEDULER  with  the  intent  to  try  aaain  at  a  later 
time. 

If  all  necessary  pages  can  be  allocated,  the  load  loon  is  entered.  Here, 
the  LOADER  sets  up  an  appropriate  I/O  parameter  table,  initiates  the  trans¬ 
fer  by  calling  PUTDRQ,  and  blocks  itself  before  returninn  to  the  SCHEDULER. 
After  the  completion  of  the  transfer,  the  Drum  Interrupt  Process  unblocks 
the  LOADER  which  continues  the  load  loop  until  all  program  panes  are  in 
core.  Thereafter,  L.;e  user  process  is  activated  (It  is  now  ready  to  run) 
and  Its  LB IT  is  reset.  Having  successfully  completed  its  task,  the  LOADER 
returns  to  tne  SCHEDULER. 


G.3  TERMINATOR 

The  TERMINATOR  is  activated  by  the  Trap  Process  which  schedules  a  user  pro¬ 
cess  for  termination  after  a  STOP,  an  illegal  instruction  trap  or  a  memory 
violation  trap.  The  TERMINATOR  finds  the  job  to  be  terminated  by  scannlna 
the  PSR  queue.  It  deactivates  itself  if  there  are  no  processes  to  be  terminat 
ed.  When  a  process  to  be  terminated  is  found,  all  its  core  panes  and  all  its 
drum  pages  except  for  the  drum  output  pane  are  deallocated.  After  its  TBIT 
is  reset,  the  user  process  Is  scheduled  for  printinn  and  PRINT  is  activated. 
The  TERMINATOR  returns  to  the  SCHEDULER. 


scan  PSRQ  for  user  process  to  be  terminated  (TBIT) 


success 


deactivate  TERMINATOR 


note  PSR  pointer  in  T$PSRPT, 
initialize  program  page  de¬ 
allocation  loop 


TSDEALLP 


more  program  pages  to  be  deallocated 


deallocate  PSR$R1  and  PSR$Pi 


T$DATA 


deallocate  drum  input  page  PSR$DI, 
reset  TBIT,  set  PBIT, 
activate  PRINT 


5.3  PRINT 


PRINT  Is  activated  by  the  TERMINATOR  when  it  schedules  a  terminated  user 
process  for  printing.  PRINT  finds  the  user  process  by  scannino  the  PSR 
queue  or  deactivates  itself  in  case  there  are  no  more  user  processes  to 
be  printed.  After  finding  a  user  process  to  be  printed,  PRINT  allocates 
a  print  buffer,  sets  up  an  I/O  parameter  table,  and  initiates  the  trans¬ 
fer  of  the  drum  output  paqe  by  calling  PUTDRQ.  After  blocking  itself  and 
being  unblocked  by  the  Drum  Interrupt  Process,  PRINT  prints  the  user's 
output  preceded  by  a  header  on  the  line  printer.  Thereafter,  the  print 
buffer,  the  user's  drum  output  page,  and  the  user’s  PSR  are  released 
and  PRINT  returns  to  the  SCHEDULER. 


5.10  TIMER  INTERRUPT  PROCESS 


Undebugged  user  programs  have  the  potential  of  execution  an  infinite  loop 
ancl  never  relinquishing  control  of  the  CPU.  To  prevent  such  an  occurrence, 
the  SCHEDULER  sets  the  timer  to  some  reasonably  large  interval  every  time 
it  gives  control  to  a  process.  A  timer  interrupt  will  occur  if  the  SCHED¬ 
ULER  does  not  regain  control  of  the  CPU  within  this  Interval. 

No  system  process  should  execute  excessively  long,  and  therefore  the 
Tinier  Interrupt  Process  will  PUNT  when  a  system  process  is  interrupted 
by  the  timer.  An  Interrupted  user  process  is  deactivated,  marked  with  the 
abnormal  termination  bit  QBIT,  and  scheduled  for  termination.  After 
activating  the  TERMINATOR,  the  Timer  Interrupt  Process  returns  to  the 
SCHEDULER. 


Code  for  the  Timer  Interrupt  Process: 


****************************************lV**ftiMW***********t*********»**** 


*  TIMER  INTERRUPT  PROCESS 


TI SENTRY:  XR  LOAD 

IF  <0  GO  TO 
PUNT 

TI$USER:  AND 

OR 
OR 

XR  LOAD 
OR 

XR  LOAD 
SWITCH  PROC 


ILC$PIT) ; 

PSR$MD.X,  TISUSER); 
•40); 

PSRSST.X,  CABIT); 
PSRSST.X,  QBIT); 
PSRSST.X,  TBIT); 
ADPSRT) ; 

PSRSST.X,  ABIT); 
LCSSCH); 

TI  SENTRY); 


W********W***iMt****t******************4******************************** 
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scheduling  system  which  formalizes  the  notion  of 
priority.  Various  classes  of  scheduling  algorithms  are 
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implemented  ones.  For  time-invariant  algorithms,  the 
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Introduction 

The  grouping  of  scheduling  algorithms  according  to 
common  features  and  parameters  [4,  10,  11,  16]  has 
resulted  in  the  definitions  of  classes  of  algorithms  which 
aid  in  analyzing  the  resulting  system  behaviors.  Owing 
to  their  extended  set  of  parameters,  however,  more 
sophisticated  algorithms  which  concern  themselves 
with  system  load  [15],  job  delay  [2],  deadlock  situa¬ 
tions  [5],  working  sets  [8],  and  so  on  are  beyond  the 
scope  of  those  classes.  In  this  paper,  a  classification 
scheme  is  suggested  which  is  applicable  to  arbitrary 
algorithms.  This  scheme  is  based  on  a  model  of  a 
generalized  scheduling  system  which  manages  the  re¬ 
sources  in  a  single  multiserver  system.  Contemporary 
general  purpose  systems  and  computer  networks  which 
involve  the  management  of  a  number  of  different  sys¬ 
tem  resources  can  be  modeled  as  a  set  of  interacting 
multiserver  systems  [1].  Owing  to  its  suitability  for 
classifying  algorithms,  the  model  leads  to  the  definition 
of  novel  classes  of  algorithms  which  are  related  to 
existing  schemes.  Furthermore  it  provides  a  framework 
for  comparing  and  evaluating  different  algorithms  in 
queueing  theoretical  terms  [17],  by  means  of  simula¬ 
tions,  and  in  real  operating  systems.  In  an  implementa¬ 
tion,  the  overhead  of  the  generalized  scheduling  system 
is  a  function  of  the  particular  algorithm  used.  A  crite¬ 
rion  for  implementation  efficiency  is  suggested,  and  the 
class  of  algorithms  satisfying  this  criterion  is  defined. 

Universal  Scheduling  System 
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A  universal  scheduling  system  (USS)  is  a  general¬ 
ized  scheduler  supporting  the  execution  of  arbitrary 
scheduling  algorithms  for  a  job  stream  arriving  at  a 
multiserver  system.  The  characteristics,  or  states,  of 
resident  jobs  are  represented  by  records  which  are 
maintained  by  the  USS.  The  arbitrary  scheduling  algo¬ 
rithm  may  vary  in  time  and  is  specified  in  terms  of 

—  a  decision  mode, 

—  a  priority  function,  and 

—  an  arbitration  rule. 

Figure  1  illustrates  the  structure  of  a  USS.  At  certain 
instants  in  time  which  are  specified  by  the  decision 
mode,  the  USS  evaluates  the  priority  function  for  all 
jobs  in  the  system.  The  job(s)  with  the  highest  priorities 
is  (are)  given  control  of  the  servers;  the  arbitration  rule 
is  applied  in  case  there  are  multiple  jobs  with  the  same 
priority  .The  USS  is  said  to  emulate  an  arbitrary  sched¬ 
uling  algorithm  in  the  sense  that  it  makes  exactly  the 
same  scheduling  decisions  at  exactly  the  same  times. 
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Fig.  1.  Structure  of  a  universal  scheduling  system. 
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The  decision  mode  characterizes  the  instants  in 
time,  or  decision  epochs,  at  which  job  priorities  are 
computed  and  compared  and  at  which  one  or  more  jobs 
are  selected  for  service.  The  set  of  jobs  being  serviced 
cannot  change  between  two  consecutive  decision  ep¬ 
ochs.  Depending  on  the  decision  mode,  algorithms  may 
be 

—  nonpreemptive, 

-quantum-oriented, 

—  preemptive,  or 

—  processor-sharing . 

In  nonpreemptive  algorithms,  jobs  are  allowed  to 
run  to  completion;  scheduling  decisions  are  only  made 
when  a  job  departs  or  when  an  arriving  job  finds  the 
system  empty.  In  quantum-oriented  algorithms,  deci¬ 
sions  are  also  made  upon  completion  of  a  quantum .  For 
infinite  quantum  sizes,  this  mode  degenerates  into  the 
nonpreemptive  mode.  In  preemptive  algorithms,  a  de¬ 
cision  is  also  made  upon  the  arrival  of  a  job.  In  other 
words,  the  decision  epochs  of  preemptive  algorithms 
are  the  set  of  all  arrival  and  departure  times  as  well  as 
the  quantum  completion  times.  Finally,  processor-shar¬ 
ing  schemes  (12)  may  be  obtained  from  quantum-ori¬ 
ented  ones  by  letting  the  quantum  size  approach  zero. 
So  far,  only  a  few  schemes,  like  round  robin  and 
feedback  [6,  18],  have  been  studied  in  processor-shar¬ 
ing  mode.  Theoretical  results  about  processor-sharing 
algorithms  serve  as  a  good  approximation  for  schemes 
with  small  quantum  sizes.  The  decision  modes  are  listed 
in  increasing  order  of  generality  in  the  sense  that  the  set 
of  decision  epochs  of  each  mode  is  a  superset  of  the 
decision  epochs  of  the  previous  modes.  While  these 
four  modes  seem  to  suffice  to  characterize  all  interest¬ 
ing  algorithms,  additional  modes  are  not  ruled  out.  At 
any  rate,  any  algorithm  can  be  emulated  in  processor¬ 
sharing  mode,  since  it  allows  decisions  to  be  made 
continuously.  However,  the  priority  function  for  a  par¬ 
ticular  algorithm  may  vary  with  the  decision  mode  in 


which  this  algorithm  is  emulated.  In  the  less  general 
modes,  it  is  sometimes  possible  to  use  simpler  priority 
functions  because  they  are  evaluated  at  discrete  inter¬ 
vals  only.  The  three  less  general  modes  are  included  in 
the  classification  scheme  because  they  allow  simple 
characterizations  of  many  algorithms  and  their  efficient 
emulation  on  a  USS. 

The  priority  function  is  an  arbitrary  function  of  job 
and  system  parameters.  At  any  time,  a  job's  priority  is 
defined  as  the  value  of  the  priority  function  applied  to 
the  current  values  of  the  parameters.  Following  Coff¬ 
man  and  Kleinrock  |4],  we  concentrate  on  naming 
parameters  of  the  priority  functions,  rather  than  trying 
to  elaborate  on  their  forms.  Some  of  the  parameters  on 
which  priorities  can  be  based  are 

—  memory  requirement, 

—  attained  service  time. 

—  total  service  time. 

—  external  priorities. 

—  timeliness. 

—  system  load. 

The  memory  requirement  serves  as  a  major  sched¬ 
uling  criterion  in  batch  processing  systems.  In  interac¬ 
tive  systems,  it  is  also  important  since  it  is  a  good 
measure  of  swapping  overhead,  but  the  attained  service 
time  is  usually  the  most  important  parameter.  Some 
systems  assume  that  the  total  service  time  of  a  job  is 
known  in  advance.  External  priorities  may  be  used  to 
differentiate  between  various  classes  of  user  jobs. 
Timeliness  takes  into  account  the  fact  that  the  urgency 
of  completing  a  job  may  vary  in  time.  The  priority  may 
increase  in  time  |2,  1 3],  or.  as  in  deadline  scheduling,  it 
may  decrease.  Greenberger’s  cost  accrual  algorithm 
represents  timeliness  in  its  most  general  form  1 10};  the 
goal  is  the  minimization  of  the  accrued  cost  due  to  the 
delay  of  all  jobs  in  the  system.  System  load  is  another 
important  parameter  owing  to  its  adverse  effect  on 
system  response.  Under  heavy  load,  some  schedulers 
attempt  to  maintain  good  response  to  high  priority  jobs 
by  discriminating  more  strongly  according  to  external 
priorities  [15],  Others  concentrate  on  reducing  swap¬ 
ping  overhead  by  varying  quantum  sizes  [7],  As  op¬ 
posed  to  the  other  parameters  we  have  listed,  system 
load  is  not  a  job  characteristic;  its  value  is  the  same  for 
all  jobs  in  the  system. 

The  arbitration  rule  resolves  conflicts  among  jobs 
with  equal  highest  priority.  Usually  a  first  in.  first  out, 
or  FIFO ,  rule  is  adopted.  Note,  however,  that  the 
arbitration  rule  can  make  the  difference  between  a 
FIFO  and  a  last  in.  first  out,  or  LIFO,  policy.  In  the 
quantum-oriented  mode,  tied  jobs  are  often  allocated 
quanta  in  a  cyclic  manner.  In  the  processor-sharing 
mode,  all  jobs  with  the  highest  priority  are  served 
simultaneously;  the  arbitration  rule  is  irrelevant.  The 
arbitration  rule  is  therefore  not  essential  for  the  specifi¬ 
cation  of  an  algorithm.  As  with  the  decision  mode,  the 
advantage  of  specifying  an  arbitration  rule  is  that  it 
simplifies  the  priority  function. 
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Priorities  and  Policy  Functions 

In  the  most  general  ease,  the  priority  of  a  job  may 
be  an  arbitrary  function  of  an  arbitrary  number  of 
parameters,  including  its  attained  processing  time  a, 
the  real  time  r  which  the  job  has  spent  in  the  computer 
system,  its  processing  requirement  /,  an  externally  as¬ 
signed  importance  factor  /,  some  measure  of  its  mem¬ 
ory  requirement  m ,  and  so  on: 

P  =  P{a,  r ,  f,  /,  m ,  .  .  .).  (1) 

Together  with  a  decision  mode  and  an  arbitration  rule, 
this  priority  function  P  defines  a  scheduling  algorithm. 
Of  col  se  any  transforms  of  the  priority  function  which 
preserve  equalities  an  inequalities  emulate  the  same 
scheduling  scheme.  Such  transforms  are  said  to  gener¬ 
ate  equivalent  priority  functions.  Table  I  lists  priority 
functions,  decision  modes,  and  arbitration  rules  for  a 
few  scheduling  algorithms. 

A  large  class  of  important  scheduling  algorithms 
can  be  defined  by  a  priority  function  of  only  three 
arguments:  P  =  P(a ,  r,  /).  Algorithms  in  this  class 
include  shortest  job  first,  shortest  remaining  service 
time  first,  longest  job  first,  and  longest  remaining  ser¬ 
vice  time  first.  A  subset  of  this  class  is  independent  of 
the  service  time  requirement  t  and  can  be  characterized 
by  a  priority  function  of  only  two  parameters:  P  = 
P(a ,  r).  Algorithms  in  this  class  are  called  unbiased 
algorithms  because  they  have  no  advance  knowledge  of 
the  job’s  total  service  requirement  /.  Unbiased  algo¬ 
rithms  include  FIFO,  service  in  random  order,  LIFO, 
round  robin,  feedback  [6|,  and  some  cost  accrual 
schemes  (10).  Unbiased  algorithms  are  widely  used  in 
real  systems,  and  many  of  their  properties  have  been 
investigated.  In  particular,  Kleinrock,  Muntz,  and  Flsu 
deriveo  t'ght  bounds  and  a  conservation  law  [14]  for 
exactly  this  class  of  algorithms. 

An  algorithm  is  called  time-invariant  if  the  differ¬ 
ence  between  the  priorities  of  two  jobs  does  not  change 
as  long  as  neither  of  them  receives  service.  Time-invar¬ 
iant  algorithms  are  particularly  efficient  to  emulate. 

Table  I.  Constants:  c,,  cy.  scheduling  parameters:  m  (memory 
requirement),  r  (real  time  in  system),  a  (attained  service  time). 
t  (total  service  time);  decision  modes:  np  (nonpreemptive),  qo 
(quantum-oriented),  p  (preemptive),  ps  (processor-sharing). 


Scheduling 

Priority 

Decision 

Arbitration 

algorithm 

function 

mode 

rule 

smallest  memory 
requirement  first 

f  ,/m  +  c,. 
-m,  etc. 

np 

arbitrary 

FIFO 

r 

np 

arbitrary 

LIFO 

~r 

np 

arbitrary 

round  robin 

0 

qo 

cyclic 

feedback 

~a 

qo 

FIFO 

preemptive  shortest  job 
first 

-t 

P 

FIFO 

processor-sharing,  long¬ 
est  remaining  service 
first 

1  -  a 

ps 

not 

applicable 
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For  algorithms  which  arc  both  time-invariant  and  un¬ 
biased.  we  conclude 

Pia,  r  +  x)  -  P(a,  r)  =  t'(.v)  (2) 

where  r(.v)  is  a  function  only  of  x  since  the  difference 
must  not  depend  on  either  a  or  r.  Equation  (2)  is  a 
special  case  of  the  Hamel  equation  |9|.  If  P(u,  r )  is 
bounded  in  any  interval,  the  unique  solution  is 

P(a,  r)  =  Cr  +  f(a)  (3) 

where  C  is  a  constant  and  f(a)  is  an  arbitrary  function  in 
a.  Note  that  P(a ,  m,  /,  r,  .  .  .)  =  Cr  +  f{a,  m,  /  ,...) 
denotes  a  more  general  class  of  time-invariant  algo¬ 
rithms. 

The  constant  C  in  eq.  (3)  plays  an  important  role. 
For  C  <  0,  a  job’s  priority  decreases  in  real  time.  Such 
a  policy  might  be  used  for  jobs  whose  quick  completion 
is  important  but  whose  timeliness  decays  in  real  time. 
Deadline  scheduling.  LIFO,  and  some  cost  accrual 
schemes  are  examples  of  such  algorithms.  For  C  =  0, 
priority  is  a  function  only  of  the  attained  service  time. 
This  is  the  case  for  feedback  schemes  which  use  a  FIFO 
arbitration  rule  (Table  I).  If f(a )  is  also  constant,  the 
operation  of  the  USS  is  determined  by  the  arbitration 
rule.  For  example,  a  quantum-oriented  mode  and  a 
cyclic  arbitration  rule  yield  the  round  robin  algorithm. 
In  the  processor-sharing  mode,  the  arbitration  rule  has 
no  effect  and  a  constant /(a)  results  in  the  processor¬ 
sharing  round  robin  algorithm.  A  positive  constant  C 
assures  that  a  job's  delay  is  given  special  consideration. 
FIFO,  the  policy-driven  scheduler  [2],  and  some  of  the 
cost  accrual  policies  belong  to  this  class.  As  indicated 
above,  feedback  schemes  may  be  specified  by  a  priority 
function  with  C  =  0  and  a  FIFO  arbitration  rule  which 
serves  to  determine  the  priorities  of  jobs  with  the  same 
attained  service  time.  Instead  of  a  FIFO  arbitration 
rule,  the  real-time  parameter  r  may  be  used  to  serve  the 
same  purpose.  In  this  case,  a  more  complex  priority 
function  with  C  >  0  results.  This  alternative  priority 
function  which  does  not  require  a  FIFO  arbitration  rule 
will  be  discussed  under  "Examples  of  Emulations.” 

If  C  is  nonzero,  eq.  (3)  may  be  divided  by  C  without 
altering  the  emulated  algorithm  since  equalities  and 
inequalities  are  preserved.  We  assume  in  the  remainder 
of  this  paper  that  priorities  are  increasing  in  real  time 
(C  >  0).  Analogous  results  can  be  obtained  with  C  <  0. 
Thus  eq.  (3)  reduces  to: 

P(a.  r)  ~r  —  F{a),  (4) 

where  the  arbitrary  function  F(a)  is  called  the  policy 
function'  of  the  unbiased  time-invariant  priority  P(a,  r). 
In  general,  time-invariant  priorities  are  characterized 
by  a  policy  function  F  of  an  arbitrary  number  of  argu¬ 
ments  (e.g.  attained  CPU  time,  working  set  size,  exter¬ 
nally  assigned  user  class,  attained  channel  time,  calls  to 

1  Fta)  is  named  after  (he  policy  function  ftr)  in  Bernstein  and 
Sharp's  policy-driven  scheduler  (6).  Note,  however,  that  fta)  actually 
corre  ponds  to  the  inverse  of /(ri.  Physical  interpretations  of  fta)  and 
its  derivative  will  he  presented. 
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the  operating  system,  etc.).  Note  that  the  dimension  of 
the  policy  function  in  eq.  (4)  is  real  time.  We  can 
therefore  plot  both  the  position  of  a  job  and  the  policy 
function  in  the  same  real-time  /  service-time  diagram . 

Figure  2  shows  the  relation  between  the  policy 
function  and  priorities  for  two  jobs  in  the  system.  In 
this  diagram,  the  priority  of  a  job  is  given  by  its  vertical 
distance  from  the  policy  function.  Independent  of  their 
values  of  r  and  a,  two  or  more  jobs  with  the  same 
vertical  distance  from  the  policy  function  will  therefore 
have  the  same  priority.  If  the  positions  of  a  group  of 
jobs  were  plotted  at  some  instant,  they  would  lie  on 
some  translation  of  the  policy  function  in  positive  or 
negative  direction  of  real  time  if  and  only  if  all  jobs  in 
this  group  have  the  same  priority.  Jobs  with  different 
priorities  will  be  positioned  on  different  translations  of 
the  policy  function,  and  no  job  can  be  positioned  above 
the  translated  policy  function  which  carries  the  group  of 
jobs  (possibly  just  one)  with  the  highest  priority.  Jobs 
below  move  upward  at  unit  rate  since  they  receive  no 
service.  They  will  receive  service  as  soon  as  they  catch 
up  with  the  highest  priority  group. 

For  the  simple  policy  function  F(a)  =  constant,  the 
priority  of  a  job  increases  linearly  with  the  time  it 
spends  in  the  system.  Independent  of  the  decision 
mode,  the  scheduling  system  will  therefore  service  jobs 
to  completion  in  the  order  of  their  arrival;  this  is  the 
FIFO  algorithm.  Similarly  any  monotonic  decreasing 
policy  function  also  yields  the  FIFO  algorithm  since  for 
such  policy  functions  the  term  ~F[a)  in  eq.  (4)  in¬ 
creases  while  a  job  is  being  serviced.  Thus  no  other  job 
can  ever  reach  the  priority  of  the  running  job. 


Equivalent  Policy  Functions 

From  the  example  of  the  FIFO  algorithm,  it  is 
apparent  that  policy  functions  do  not  map  one-to-one 
into  algorithms.  Rather  it  has  been  argued  that  all 
monotonic  decreasing  policy  functions  map  into  the 
same  algorithm.  In  general  an  arbitrary  policy  function 
can  be  replaced  by  a  unique  equivalent  policy  function. 

Consider  the  case  of  a  policy  function  with  a  local 
maximum  as  depicted  in  Figure  3  and  assume  the  deci¬ 
sion  mode  of  processor  sharing.  Suppose  that  after  R 
seconds  in  the  system  a  test  job  has  reached  m  seconds 
of  service,  where  m  denotes  the  local  maximum  of  the 
policy  function.  Suppose  also  that  the  test  job  is  cur¬ 
rently  being  serviced,  i.e.  it  is  in  the  highest  priority 
group,  and  that  the  attained  service  times  of  all  other 
jobs  in  this  group  are  outside  the  range  [m,  f>],  where 
F{b)  ~  F\m).  The  priority  of  all  jobs  in  the  highest- 
priority  group  at  this  instant  is  P(m ,  R)  =  R  -  F(m). 
Owing  to  the  decreasing  values  of  the  policy  function 
above  m ,  the  test  job  gains  priority  faster  than  the  other 
jobs  and  seizes  the  server  until  it  reaches  b  seconds  of 
service.  At  that  point,  its  priority  is  again  the  same  as 
that  of  the  other  jobs  which  have  previously  been  in  the 
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highest  priority  group,  namely  R  +  (b  -  m)  -  F(b)  or 
R  +  (b  -  m)  -  F(tn)  or  P(m,  R  +  (b  -  m )).  Thus,  after 
reaching  b  seconds  of  service,  the  test  job  will  again 
share  the  facility  with  the  other  highest  priority  jobs. 
But  exactly  the  same  scheduling  sequence  would  have 
been  achieved  if  the  valley  of  the  policy  function  F(a) 
between  m  and  b  had  been  replaced  by  a  horizontal 
line.  This  is  due  to  the  fact  that  all  highest  priority  jobs 
remain  on  the  same  translation  of  the  policy  function 
while  the  test  job  is  being  serviced  over  the  horizontal 
portion.  Note  that  the  equality  of  priorities  would  be 
disturbed  if  any  other  job  in  the  highest  priority  group 
were  serviced. 

Consider  next  the  case  of  a  policy  function  with  a 
countable  number  of  local  maxima  as  illustrated  in 
Figure  4.  Assume  also  that  a  number  of  highest  priority 
jobs  have  attained  values  of  the  service  time  which 
correspond  to  local  maxima  of  F(a).  In  this  case,  differ¬ 
ent  scheduling  sequences  may  result  for  different 
shapes  of  the  policy  function  between  the  local  max¬ 
ima.  For  continuously  distributed  interarrival  times, 
the  probability  that  two  jobs  reside  on  local  maxima  at 
the  same  time  is  zero  and  such  a  possibility  will  be 
ignored.  Thus,  assuming  continuously  distributed  inter¬ 
arrival  times,  an  arbitrary  policy  function  may  be  re¬ 
placed  by  an  equivalent  monotonic  increasing  policy 
function,  which  emulates  the  same  algorithm.  It  can  be 
shown  that  this  result  is  true  for  arbitrary  arrival  proc¬ 
esses.2  A  unique  normalized  policy  function  can  be 
obtained  from  this  equivalent  monotonic  increasing 
one  by  adding  a  constant  such  that  F\ 0)  =  0.  In  the  real- 
time  /  service-time  diagram,  the  priority  of  all  jobs 
residing  on  the  normalized  policy  function  is  therefore 
equal  to  zero. 

While  normalization  by  adding  a  constant  to  a  pol¬ 
icy  function  will  always  preserve  the  scheduling  se¬ 
quences  of  jobs  passing  through  the  system,  a  word  of 
explanation  is  in  order  about  the  scope  of  the  equiva¬ 
lence  of  monotonic  increasing  policy  functions.  This 
equivalence  was  shown  to  be  valid  for  jobs  which  are 
continuously  serviced  in  the  highest  priority  group.  If  a 
given  policy  function  assures  that  all  jobs  which  have 
joined  the  highest  priority  group  will  remain  in  the 
highest  priority  group  until  they  depart,  it  follows  that 
the  equivalent  monotonic  increasing  policy  function 
will  result  in  identical  scheduling  sequences  for  all  jobs. 
On  the  other  hand,  if  the  form  of  a  given  policy  func¬ 
tion  permits  the  priority  of  the  highest  priority  group  to 
assume  values  less  than  F(0),  the  priority  of  an  arriving 
job.  then  the  replacement  of  a  valley  of  this  function  by 
a  horizontal  line  may  decrease  a  job's  priority  below 
/TO).  This  may  lead  to  preemption  of  the  highest  prior¬ 
ity  group  by  the  new  arrival  and  thus  change  the  sched¬ 
uling  sequence  with  respect  to  the  new  arrival.  But 
since  a  job  cannot  attain  more  service  than  real  time  in 


1  This  derivation  involves  the  higher  order  derivatives  of  F\a). 
Since  il  is  beyond  the  scope  of  this  paper,  it  will  not  be  presented 
here. 
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Fig.  2.  Priorities  derived  from  a  policy  function:  Pi  a.  r)  =  r  -  F(u). 


Fig.  3.  Policy  function  with  a  local  maximum  and  its  equivalent. 


Fig.  4.  Policy  function  and  its  normalized  equivalent. 


the  system  (a  <  r),  its  priority,  defined  in  eq.  (4). 
cannot  be  less  than  the  priority  F(0)  of  an  arriving  job 
unless  F(a)  >  F( 0)  +  a  for  some  range  of  a.  Conse¬ 
quently  the  replacement  of  an  arbitrary  policy  function 
F(a)  by  its  equivalent  monotonic  increasing  one  will 
preserve  the  scheduling  sequences  of  all  jobs  passing 
through  the  system  if  all  local  maxima  F(mf)  satisfy 
F(m;)  s  F( 0)  +  m,  (cf.  Figure  4).  Otherwise  preemp¬ 
tion  is  possible  and  only  the  relative  scheduling  se¬ 
quences  of  preempted  highest  priority  groups  are 
preserved. 


Processor  Sharing  at  Different  Rates 


For  the  processor-sharing  case,  the  shape  of  the 
normalized  policy  function  lends  itself  to  an  interpreta¬ 
tion  of  its  physical  meaning.  As  outlined  in  the  previous 
section,  a  zero  slope  may  allow  a  job  to  seize  the 
processor.  Conversely  a  very  steep  slope  causes  a  job  to 
lose  priority  quickly.  In  general;  the  processing  rate  of 
a  job  is  closely  related  to  the  derivative  of  the  policy 
function  at  the  point  corresponding  to  the  job's  at¬ 
tained  service  time. 

This  result  can  be  demonstrated  as  follows.  Assume 
that  at  time  r  the  USS  services  n  jobs  with  the  same 
highest  priority  P  simultaneously  on s  servers  and  that// 
is  greater  than  or  equal  tos.  Assume  also  that  job  /  (/'  = 
1,  2,  .  .  .  ,  n)  has  been  in  the  system  forr,  seconds  and 
has  attained  a,  seconds  of  service.  Then 

P  =  r,—  Fta(),  /'  =  1,2,  (5) 

After  an  infinitesimal  time  interval  A r,  each  of  the  n 
jobs  has  gained  A af  seconds  of  service,  and  the  priority 
of  the  n  jobs  has  changed  to 

P  +  A P  ~  r,  +  Ar  -  P(flj  +  A «;)>  (6) 

where 

M 

sAr  =  2  Aflj-  (7) 

1 

A  Taylor  series  expansion  of  F,  cancellation  of  the  term 
P.  dividing  by  Ar,  and  taking  the  limit  yields  an  expres¬ 
sion  for  the  fraction  of  real  time  each  job  gained  in 
service: 


lim 

Ar-*o 


Aoj  1  -  (AP/Ar) 

—  =  lim - - - 

A r  ir->n  F  (a,) 


s/lM/FXa,)) 

F'(ai) 


K 

Fia,r 


i  =  I,  2,  .  .  .  n. 


K  >  0, 


(8) 


where  K  is  a  proportionality  factor  which  depends  on 
the  number  of  servers,  the  policy  function,  the  number 
of  jobs  in  the  highest  priority  group,  and  their  attained 
service  times.  Equation  (8)  states  that  the  service  rates 
of  a  job  in  the  highest  priority  group  is  inversely  pro¬ 
portional  to  the  derivative  of  the  policy  function  evalu¬ 
ated  for  its  attained  service.  This  result  is  the  micro¬ 
scopic  equivalent  of  the  well-known  fact  that  the  aver- 
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age  service  rate  of  a  job  is  identical  to  the  inverse  of  the 
derivative  of  the  response  function  (the  average  amount 
of  real  time  a  job  spends  in  the  system  as  a  function  of 
its  service  time)  (14.  17). 

The  service  rate  involves  the  factor  K,  which  can  be 
interprc  d  with  respect  to  the  dynamic  upward  and 
downward  motion  of  the  translation  of  the  policy  func¬ 
tion  carrying  the  highest  priority  jobs.  Since  the  dis¬ 
tance  of  this  translation  from  the  normalized  policy 
function  is  identical  to  the  priority  of  the  jobs  it  carries, 
the  rate  at  which  this  translation  moves  is  given  by  the 
quantity  lim(AP/Ar)  =  1  —  K.  Jobs  with  the  same 
priority  are  effectively  in  a  group,  and  no  job  will  leave 
the  group  until  it  is  completed.  While  the  priority  of  the 
highest  priority  group  changes  at  a  rate  of  1  -  K.  the 
priorities  of  all  other  groups  change  at  unit  rate  since  no 
service  is  attained.  A  lower  priority  group  may  there¬ 
fore  merge  with  the  highest  priority  group.  On  the 
other  hand,  the  highest  priority  group  may  be 
preempted  by  a  group  of  newly  arriving  jobs  with 
higher  priority.  From  eq.  (8)  it  can  be  seen  that  not  all 
jobs  in  the  highest  priority  group  need  to  receive  ser¬ 
vice  simultaneously.  First,  if  the  derivative  F'(a)  is  zero 
in  some  region,  one  or  more  jobs  may  seize  the  proces¬ 
sors).  Second,  if  the  derivative  F'(a)  is  infinite  for 
some  value  of  the  attained  service,  one  or  more  jobs 
may  relinquish  the  processor(s).  On  the  other  hand, 
with  a  strictly  monotonic  increasing  policy  function 
with  finite  derivatives,  all  jobs  which  have  ever  re¬ 
ceived  service  simultaneously  will  always  be  serviced 
simultaneously . 

The  special  case  of  a  linear  policy  function  whose 
slope  approaches  infinity  deserves  some  attention.  Un¬ 
der  such  an  algorithm,  jobs  lose  priority  at  a  rate 
approaching  infinity  as  soon  as  they  receive  service. 
Their  priority  increase  due  to  the  time  they  spend  in  'he 
system  becomes  negligible.  Thus  the  jobs  with  the  least 
amount  of  attained  service  have  the  highest  priority. 
This  is  the  strategy  of  the  processor-sharing  feedback 
(FB)  scheme  [6|.  In  general  any  "vertical"  policy  func¬ 
tion  which  is  the  limit  of  a  monotonic  increasing  policy 
function  will  emulate  the  processor-sharing  FB 
algorithm. 

In  the  general  case,  the  policy  function  is  a  function 
of  n  arguments  (service  time,  memory  requirement, 
operating  system  calls,  channel  time,  etc.),  and  its  de¬ 
rivative  is  a  weighted  sum  of  n  partial  derivatives.  The 
display  of  such  a  policy  function  requires  an  (n  +  1)- 
dimensional  space.  An  interesting  case  arises  when  the 
policy  function  is  a  function  of  a  linear  combination 
of  its  parameters:  F(c,a,  4-  c2a2  +  ■■■  +  crar).  If  a 
“generalized  attained  service”  a  is  substituted  for  this 
combination  of  weighted  parameters,  the  results  about 
normalized  policy  functions  and  processor  sharing  at 
different  rates  remain  valid.  The  policy  function  can  be 
displayed  as  in  Figure  2,  the  sum  of  partial  derivatives 
degenerates  into  a  total  derivative  with  respect  to  the 
generalized  service,  and  the  relative  service  rates  re¬ 
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main  inversely  proportional  to  this  derivative.  At  least 
two  real  systems  utilize  the  notion  of  such  a  generalized 
service  in  their  schedulers;  in  the  policy-driven  schedu¬ 
ler  on  the  GE  635  of  the  General  Electric  Research  and 
Development  Center  [2],  it  is  measured  in  terms  of 
"resource  units,"  and  the  System  Resources  Manager 
in  IBM's  VS2/2  expresses  the  service  rate  in  terms  of 
"service  units"  per  second  [15]. 

Implementation 

A  prominent  feature  of  the  USS  is  its  suitability  for 
both  theoretical  and  experimental  approaches.  Imple¬ 
menting  a  scheduler  as  a  USS  allows  algorithms  to  be 
changed  easily  over  a  wide  range.  Moreover,  such 
changes  may  be  instigated  either  externally  or  inter¬ 
nally.  Of  course,  it  is  often  unrealistic  to  emulate  a 
processor-sharing  algorithm  because  of  excessive  over¬ 
head.  But  even  for  algorithms  which  do  not  employ 
processor  sharing,  the  issue  of  overhead  arises  in  the 
context  of  computing  and  comparing  the  priorities  of  all 
jobs  at  every  decision  epoch. 

The  importance  of  time-invariant  priorities  be¬ 
comes  apparent  in  this  context.  While  any  time-invaT- 
iant  algorithm  can  be  implemented  in  the  way  sug¬ 
gested  below,  we  shall  continue  to  use  the  example  of 
unbiased  time-invariant  algorithms  as  an  illustration. 
Equation  (4)  shows  that  for  such  algorithms  priorities 
change  linearly  in  real  time  unless  a  job  attains  service. 
Determining  the  real  time  r  which  a  job  has  spent  in  the 
system  from  its  time  of  arrival  e  and  the  current  real 
time  c, 

r  =  c  -  e,  (9) 

and  subtracting  the  current  time  c  from  all  job  priorities 
(which  preserves  equalities  and  inequalities)  changes 
eq.  (4)  to 

P(a,  c  -  e)  -  c  =  -e  —  F(a).  (10) 

The  priority  measure  in  eq.  (10)  is  particularly 
suited  to  an  efficient  implementation.  Since  this  mea¬ 
sure  is  independent  of  real  time,  job  entries  can  be 
ordered  in  a  queue  according  to  decreasing  priorities. 
At  a  decision  epoch,  the  USS  therefore  need  not  com¬ 
pute  the  priorities  of  all  jobs  but  simply  picks  the  job(s) 
at  the  head  of  the  queue  for  execution.  The  priorities  of 
the  preempted  jobs  are  recomputed  and  their  entries 
are  inserted  into  the  queue  according  to  these  new 
values.  Essentially  this  is  the  scheme  implemented  in 
the  policy-driven  scheduler  [2].  There  the  policy  func¬ 
tion  is  a  function  of  the  user  class  and  of  a  linear 
combination  of  attained  services  measured  in  resource 
units.  The  queue  is  ordered  in  increasing  order  of  the 
negative  priority  measure  of  eq.  (10),  and  special  rules 
have  been  introduced  to  govern  the  swapping  activities. 
The  original  implementation  of  this  scheduler  was  not 
time-invariant  and  required  an  excessive  amount  of 
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Table  II.  Decision  modes:  np  (nonpreemptive),  qo  (quantum- 
oriented),  pr  (preemptive),  ps  (processor-sharing);  scheduling 
parameters:  r  (real  time  in  system),  t  (user  class),  R  (generalized 
attained  service),  a  (attained  service),  q  (quantum  size). 


Scheduling 

Priority 

Policy 

Decision 

Arbitra- 

algorithm 

function 

function 

mode 

tion  rule 

FIFO 

r 

0 

np 

random 

policy -driven 
scheduler[2] 

r  -f  Hi,  R) 

/  ‘0,  R) 

qo 

FIFO 

two-level 

preemptive 

feedback 

r,  for  a  s  q , 
r  - 

for  a  >  q 

0, 

for  a<ij. 

X 

for  a  >  q 

pr 

FIFO 

processor-shar¬ 
ing  feedback 

r  — 

ka 

limk^«  ka 

ps 

not 

applicable 

computation  for  its  execution.  A  minor  change  in  the 
algorithm,  which  converted  it  into  a  time-invariant 
one,  resulted  in  a  significant  improvement  of  system 
behavior. 


Examples  of  Emulations 

Many  algorithms  are  based  on  the  notion  of  job 
classes.  Job  classes  serve  to  identify  jobs  with  related 
priorities  and  can  be  defined  in  terms  of  arbitrary  job 
parameters.  Depending  on  the  definition,  a  job  may  or 
may  not  change  class  membership  during  its  lifetime  in 
the  system.  If  the  priorities  of  jobs  in  one  class  are 
always  to  be  higher  (or  lower)  than  the  ones  in  another 
class,  independent  of  how  long  they  have  b *  >  •?  the 
system,  the  priorities  of  the  two  classes  on  a  ,  SS  must 
differ  by  an  infinite  amount.  Conventional  schedulers 
typically  maintain  a  separate  queue  for  each  class.  The 
most  common  example  for  these  algorithms  is  the 
group  of  n-level  feedback  algorithms  [6],  where  class 
membership  is  based  on  the  attained  service.  This 
group  can  be  emulated  by  using  the  policy  function 

F(a)  =  linr_*  iz,  for  q,  <  a  <  q,,t; 

where  i  =  0,  1 . n  —  1 ;  q0  =  0,  q„  =  x.  (II) 

Theoretically  the  limit  in  this  equation  is  necessary  to 
guarantee  the  correct  emulation  when  the  real  time  of  a 
job  in  the  system  approaches  infinity.  For  all  practical 
purposes,  however,  this  limit  can  be  approximated  by 
using  a  large  positive  integer  for  z.  Jobs  which  have 
acquired  fewer  than  qx  seconds  of  service  are  treated  in 
a  FIFO  fashion.  When  a  job  has  received  q,  seconds  of 
service,  its  priority  jumps  to  r  -  thus  effectively 
preventing  any  service  allocation  as  long  as  there  are 
jobs  with  fewer  than  qx  seconds  of  service  in  the  system. 
After  the  ith  quantum  qit  priority  is  reduced  to  r  -  iz , 
delaying  servi.e  until  all  jobs  have  received  i  quanta . 

The  multilevel  feedback  algorithms  (14]  represent  a 
generalization  of  the  n-level  feedback  algorithms. 
While  the  latter  treat  all  jobs  on  one  level  in  FIFO 
fashion,  multilevel  feedback  algorithms  allow  for  the 


specification  of  either  FIFO,  processor-sharing  round 
robin,  or  processor-sharing  FB  for  every  level.  As  for 
the  n-ievel  feedback  scheme,  the  job  class  on  level  i 
may  be  assigned  a  range  of  priority  numbers  such  that 
—iz  ^  P  <  -(/  —  1  )z.  The  priority  function  Piu,  r )  is,  of 
course,  a  generalization  of  the  priority  function  for  n- 
level  schemes: 


P(a,r) 

(r  -  zi. 


for  FIFO, 
for  psRR. 

(1/2)(1  -  (a  -q,)/(q,^  -<?,))], 
for  psFB, 


(12) 


where  q,  s  a  < 

and  /  =  0,  1 ,  .  .  .  ,  n  -  1 ;  q„  =  0;  q„  =  x. 


If  only  FIFO  and/or  processor-sharing  FB  are  specified 
for  the  n  levels,  the  policy  function  F{a)  can  be  deter¬ 
mined  directly  from  the  relation  P(a,  r)  =  r  -  F(a).  If 
processor-sharing  round  robin  is  also  specified  for  one 
or  more  levels,  the  constant  C  in  eq.  (3)  is  zero  and  eq. 
(12)  cannot  uniformly  be  divided  by  C  to  yield  F(a). 
The  priority  measure  of  eq.  (10)  remains  valid,  how¬ 
ever,  if  the  time  of  arrival  e  is  defined  to  be  a  constant 
for  all  job  classes  on  processor-sharing  round  robin 
levels. 

The  policy-driven  scheduler  [2]  deserves  special 
credit  for  proving  the  feasibility  of  implementing  a 
scheduler  based  on  a  functional  parameter  — the  policy 
function  — in  a  production  oriented  system.  In  this  in¬ 
stallation,  the  policy  function  f~x(i,  R)  is  a  function  of 
the  user  class  i  and  of  “resource  units"  R ,  a  linear 
combination  of  various  attained  services.  The  specifica¬ 
tions  for  this  scheduler  as  well  as  for  a  number  of  other 
time-invariant  algorithms  are  summarized  in  Table  II. 

The  selfish  round  robin  (SRR)  algorithms,  which 
include  FIFO  and  processor-sharing  round  robin,  are 
defined  in  terms  of  two  parameters  a  and  p ,  or  equiva¬ 
lently  in  terms  of  two  job  classes  [11].  The  priority  of 
jobs  in  the  highest  priority  group  increases  at  a  rate  p, 
while  all  other  jobs  gain  priority  at  a  rate  a,  where 
0  s  p  s  a.  Since  an  arriving  job  gains  priority  at  a 
higher  rate,  it  will  eventually  catch  up  with  the  highest 
priority  group,  say  after  a  waiting  time  W.  Thereafter  it 
will  share  the  facility  equally  with  the  other  highest 
priority  jobs.  SRR  algorithms  are  emulated  by  the 
priority  function 


P(r,  W)  = 


ar, 

aW  +  p(r  -  W), 


for  r  s  W, 
for  r  <  W, 


(13) 


or,  after  dividing  by  a. 


P(r ,  W) 


{  r ,  for  r  ■£  W, 

\(P/a)r  -  W(/3/a  ~  D,  for  r  >  W.  '  ' 


Note  that  P(r,  W)  =  r  if  y8  =  o;  this  priority  function 
specifies  the  FIFO  algori*hm  (policy  function  F(a)  =  0). 
If  p  =  0,  the  first  job  in  a  busy  period  will  retain  a  zero 
priority  because  its  waiting  time  W  is  zero.  Since  its 
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priority  is  also  the  highest  priority  in  the  system,  how¬ 
ever,  all  new  arrivals  with  priority  P(r  =  0,  VF)  =  0  will 
immediately  join  the  highest  priority  group.  Thus  a 
SRR  algorithm  with  (3  =  0  specifies  a  zero  priority 
function  which  emulates  the  processor-sharing  round 
robin  algorithm. 

Chua  and  Bernstein  [3]  have  analyzed  a  parameter¬ 
ized  model  which  lends  itself  to  an  analysis  of  a  class  of 
feedback  algorithms.  This  model  is  quantum-oriented 
and  makes  use  of  a  queue  with  numbered  positions. 
Position  1  contains  the  job  being  serviced.  After  receiv¬ 
ing  its  /'th  quantum,  a  job  is  fed  back  into  queue  posi¬ 
tion  ir,,  where  the  set  of  ir/sf/  =  0,  1,  2, .  .  .)  specifies  a 
particular  algorithm.  Special  rules  govern  collisions 
with  new  arrivals  and  ensure  that  all  jobs  in  the  system 
are  placed  in  contiguous  positions  at  the  top  of  the 
queue.  After  a  quantum,  the  new  position  of  any  job 
can  be  defined  as  a  function  of  its  previous  position,  the 
set  of  77, 's,  the  number  of  jobs  in  the  system,  whether 
there  is  a  new  arrival  or  not,  and  the  number  of  at¬ 
tained  quanta  as  well  as  the  total  service  requirement  of 
the  job  leaving  position  1 .  Since  the  priority  of  a  job  is 
monotonic  decreasing  with  its  queue  position,  any 
monotonic  decreasing  function  of  the  function  for  the 
new  position  will  serve  as  the  priority  function  emulat¬ 
ing  the  algorithm  specified  by  the  set  of  m's.  In  the 
general  case,  such  an  algorithm  will  not  be  time-invar¬ 
iant  since  jobs  being  fed  back  may  be  inserted  between 
two  previously  contiguous  jobs  in  the  queue. 

The  derivation  of  the  policy  function  F(a)  for  time- 
invariant  unbiased  algorithms  was  based  on  the  as¬ 
sumption  of  a  positive  constant  C  in  eq.  (3).  For  algo¬ 
rithms  which  cause  a  job's  priority  to  decrease  in  real 
time,  however,  this  constant  must  be  negative.  The 
class  of  time-invariant  unbiased  algorithms  actually 
consists  of  three  subclasses  which  are  characterized  by 

C  =  0.  C  >  0,  and  C  <  0. 

The  latter  two  subclasses  contain  the  same  number  of 
algorithms  and,  moreover,  form  a  duality.  For  any 
algorithm  with  C  <  0,  the  priority  function  (cf.  eq.  (4j) 
can  be  expressed  as 

P(a.  r )  =  -( r  -  GUt  I). 

In  the  real-time  /  service-time  diagram,  the  priority 
is  still  proportional  to  the  vertical  distance  of  a  job  from 
the  "policy  function"  (Ha),  but  with  opposite  sign. 
Thus  the  highest  priority  jobs  are  positioned  on  the 
lowest  translation  of  (Ha),  and  all  other  jobs  must 
necessarily  reside  above  this  translation.  Normalization 
of  an  arbitrary  G(«)  results  in  a  monotonic  decreasing 
function,  and  the  derivative  of  a  normalized  G(«)  is 
inversely  proportional  (but  with  opposite  sign)  to  the 
service  rate  of  a  job  in  the  highest  priority  group.  The 
term 

Ptn,  c-e)  +  c=  eJ-  G(tt ) 

may  be  used  as  an  efficient  priority  measure  in  imple¬ 


mentations  (cf.  eq.  (10)).  To  summarize,  for  every 
algorithm  P{a,  r)  =  r  -  F{ti)  in  subclass  C  >  0  there 
exists  a  dual  algorithm  P(a,r)  =  -(r  -  G(a))  in  subclass 
C  <  0,  where  G(a)  =  - F(a)  and  dual  physical  interpre¬ 
tations  hold.  In  contemporary  computer  systems, 
scheduling  algorithms  with  C  <  0  are  not  common,  but 
LIFO  is  an  important  algorithm  for  many  applications 
in  operations  research.  Clearly  LIFO  is  the  dual  algo¬ 
rithm  to  FIFO,  since  it  can  be  emulated  with  G(a)  =  0 
or  P(a ,  r )  =  — r. 


Summary 

The  model  of  a  USS  provides  a  unifying  mechanism 
for  dealing  with  arbitrary  scheduling  algorithms.  Some 
algorithms  define  priorities  in  terms  of  queue  struc¬ 
tures.  while  others  base  their  decisions  on  priority  num¬ 
bers.  In  formalizing  the  notion  of  job  priority,  the  USS 
relates  these  two  approaches  and  provides  the  basis  for 
comparing  and  evaluating  different  algorithms.  The 
model  suggests  a  rather  natural  classification  scheme  in 
terms  of  decision  mode,  priority  function,  and  arbitra¬ 
tion  rule  and  leads  to  the  definition  of  various  classes, 
including  the  unbiased  and  the  time-invariant  schedul- 
itg  algorithms.  Algorithms  which  are  not  time-invar¬ 
iant  can  be  specified  in  terms  of  priority  functions. 
Policy  functions  can  be  used  to  emulate  time-invariant 
algorithms.  The  derivatives  of  normalized  policy  func¬ 
tions  are  shown  to  control  the  relative  service  rate  of  a 
job  as  a  function  of  its  attained  service.  Furthermore, 
the  duality  among  time-invariant  unbiased  algorithms  is 
pointed  out. 

The  USS  is  more  than  a  theoretical  tool,  however. 
It  lends  itself  to  an  efficient  implementation  for  time- 
invariant  policies.  In  such  an  implementation,  the  over¬ 
head  oc.  trs  at  decision  epochs  and  consists  of  comput¬ 
ing  priority  measures  for  the  preempted  jobs  and  in¬ 
serting  them  into  an  ordered  queue.  For  some  simple 
algorithms,  this  overhead  may  be  slight’  ,  higher  than 
for  a  conventional  scheduler  which  does  not  use  a 
function  as  a  priority  measure.  For  more  sophisticated 
algorithms,  a  USS  provides  a  flexible,  efficient,  and  yet 
uniform  framework  for  implementation.  Arbitrary  pa¬ 
rameters.  including  system  load,  job  delay,  and  so  on. 
may  be  considered  and  the  scheduling  algorithm  may 
be  modified  while  the  system  runs,  either  dynamically 
or  by  external  intervention. 

Designed  to  consider  a  minimum  level  of  acceptable 
service  specified  via  a  policy  function  for  each  user 
group,  the  policy-driven  scheduler  (2)  represents  an 
implementation  for  time-invariant  algorithms.  The  re¬ 
sults  concerning  emulation,  equivalence  of  policy  func¬ 
tions.  and  the  relationship  between  policy  functions 
and  processing  rates  are  directly  applicable  to  this 
scheduler  and  demonstrate  its  potential  generality. 
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ABS.MA£I 

This  paper  presents  an  analysis  of  time-sharing 
computer  facilities  with  scheduling  algorithms  defined  in 
terms  of  priority  functions.  We  consider  the  class  of 
algorithms  in  which  a  job's  priority  is  defined  by  the 
difference  between  the  time  it  spent  in  the  system  and  an 
arbitrary  function  F  of  its  attained  service,  where  F  is 
called  the  policy  function. 

Our  main  result,  the  average  response  time  for  a  job 
conditioned  on  its  service  requirement,  applies  to  a  broad 
class  of  policy  functions.  The  derivation  is  based  on  the 
model  of  a  processor-sharing  M/G/1  queuing  system  and  does 
not  use  transforms.  A  method  involving  the  decomposition  of 
a  non-Markov ian  process  is  shown  to  simplify  the  analysis. 

Properties  of  the  average  response  time  resulting  from 
policy  function  schedulers  are  discussed  and  related  to 
those  of  other  known  time-sharing  scheduling  algorithms. 
For  the  examples  of  linear,  exponential,  and  composite 
policy  functions  we  plot  the  response  times.  The 
flexibility  and  the  limitations  of  policy  functions  with 
respect  to  the  discriminatory  treatment  of  short  jobs  versus 
long  ones  are  demonstrated,  and  the  optimal  selection  of  a 
policy  function  with  respect  to  a  given  overall  performance 
criterion  is  discussed. 
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M  M4LXX1SAL  XBE&1MENT  QL  RQLIQX  HULQIIZR  SCHEDULERS 


Bernstein  and  Sharp  [3]  designed  and  implemented  the 
first  policy  function  scheduler  in  1969-  This  scheduler 
attempted  to  avoid  unnecessary  system  overhead,  in 
particular  swapping,  by  specifing  (and  adhering  to)  a 
minimal  level  of  acceptable  service  to  users.  Parameterized 
scheduling  algorithms  have  allowed  system  designers  and 
installation  managers  to  tune  systems  before,  but  the  use  of 
arbitrary  functions,  rather  than  discrete  parameters, 
permits  a  more  flexible  specification  of  the  desired  system 
behavior.  It  is  an  indication  of  their  usefulness  that 
variations  of  policy  function  schedulers  have  since  been 
adopted  for  production  systems,  e.g.  IBM's  0S/VS2  Release  2 
[8],  as  well  as  research  oriented  systems  like  HYDRA  [6). 
The  implementations  of  these  schedulers  have  not  been 
without  problems.  It  is  tempting  to  increase  the  level  of 
sophistication  of  a  policy  function  to  a  point  where  the 
incurred  overhead  exceeds  the  gain  in  the  quality  of 
servJce.  Pur  l>er  »r.cre ,  with  few  theoretical  results 
available,  the  choices  of  the  forms  and  of  the  arguments  of 
policy  functions  are  often  based  on  intuition. 
Consequently,  the  process  of  tuning  a  system  tends  to 
proceed  in  an  ad-hoc  fashion  and  little  insight  is  gained 
with  respect  to  the  intrinsic  characteristics  of  policy 


function  schedulers. 


Any  scheduling  algorithm  can  be  expressed  as  a  priority 


scheduling  algorithm.  In  the  latter,  the  scheduler 
evaluates  a  priority  .fun  Ct  la  a  P(P1»PZ.P3»  •••)  of  an 

arbitrary  number  of  job  parameters  p*  (service  time,  memory 
requirement,  system  calls,  channel  time,  external  job  class, 
etc.)  for  all  competing  jobs  and  allocates  the  resource(s) 
to  the  job(s)  with  the  highest  priority  value(s).  We  shall 
review  some  of  the  general  properties  of  such  priority 
functions.  For  a  more  comprehensive  treatment  as  well  as  a 
general  introduction  to  priority  scheduling  algorithms  the 
reader  is  referred  to  Ruschitzka  and  Fabry  [10].  It  was 
shown  there  that  the  overhead  for  evaluating  the  priority 
function  can  be  considerably  reduced  if  the  priority 
function  is  of  the  form 

P  (  n  i  P^  » P3  1  •  •  •  )  =  Cr  —  f  (  P^  ,  Pj  ,...),  (1) 

where  the  first  job  parameter,  r,  is  the  real  time  a  job  has 
spent  in  the  system,  C  is  a  constant,  and  the  arbitrary 


function 

f  of  the 

remaining 

job 

parameters  is 

called 

the 

J2Qj.lc_y 

f UhQtiQU . 

Note 

that 

equation  (1) 

defines 

the 

relation 

bt  tween 

pol  Icy 

functions  arid  the 

notion 

of 

priorities.  The  choice  of  the  instants  in  time  at  which  the 
priority  function  P  is  evaluated  characterizes  a  scheduling 
algorithm  as  non-preemptive ,  preemptive,  quantum-oriented, 
processor-sharing,  etc..  Processor- sharing  algorithms  are 
the  most  general  in  that  they  can  be  used  to  simulate  all 
others  [10].  Because  of  this  generality  and  also  because  of 


the  appealing  simplicity  of  the  analytical  results,  only 
processor-sharing  algorithms  will  be  considered  henceforth. 


If  the  constant  C  in  equation  (1)  is  negative,  a  job's 
priority  decreases  in  real  time.  Such  a  priority  function 
would  be  used  to  implement  deadline  scheduling  or  LIFO.  If 
C=0,  the  priority  is  independent  of  real  time.  We  are 
interested  in  the  case  C>0,  i.e.  those  algorithms  in  which 
a  job's  priority  increases  with  the  time  it  spends  in  the 
system.  In  this  case,  the  term  on  the  right  hand  side  of 
equation  (1)  can  be  divided  by  C  without  changing  the 
algorithm,  since  equalities  and  inequalities  of  the 
priorities  of  any  two  jobs  are  preserved.  Furthermore,  if 
the  policy  function  is  a  function  of  only  the  attained 
service  time,  a,  the  priority  function  specializes  to 

P(r ,a)  =  r  -  F(a)  ,  (2) 

where  the  new  policy  function  F( a )  is  simply  f(a)/C.  In 
this  paper,  we  consider  only  the  class  of  algorithms  defined 
by  priority  functions  of  the  form  of  equation  (2). 
Different  forms  of  the  p-’llcy  function  F(a)  define  different 
algorithms,  and  for  a  variety  of  conventional  time-sharing 
algorithms  the  defining  policy  functions  are  known.  For 
example,  F(a)=d,  where  d  is  any  constant,  specifies  the  FIFO 
algorithm  since  the  priority  of  a  job  will  increase  linearly 
with  the  time  it  spent  in  the  system.  We  briefly  summarize 
two  results  concerning  the  equivalence  and  the  normalization 
of  policy  functions  [10].  Policy  functions  are  called 
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equivalent  if  their  evaluations  result  in  identical 
scheduling  sequences.  Thus,  the  policy  functions  Ft(a)=0 
and  F^(a)=d  (d*0)  are  equivalent  since  both  yield  the  FIFO 
scheduling  sequence.  However,  any  set  of  equivalent  policy 
functions  {F}  can  be  represented  by  a  unique  normalized 
policy  function  which  is  (weakly)  monotonic  increasing  and 
satisfies  F(0)=0  [10].  For  FIFO,  the  normalized  policy 
function  is  F(a)=0.  Without  loss  of  generality,  policy 
functions  are  assumed  to  be  normalized  in  the  sequel. 

JL.  ML  MU  AEPBQ1CH 

It  is  our  goal  to  derive  the  relationship  between  a 
given  policy  function  and  the  resulting  system  behavior.  We 
shall  use  the  response  function ,  the  average  time  a  job 
spends  in  the  system  conditioned  on  its  service  requirement, 
to  describe  the  system  behavior  in  equilibrium.  The  system 
is  modeled  by  an  M/G/1  queuing  system,  i.e.  a  system  with 
Poisson  Job  arrivals,  a  general  (arbitrary)  distribution  of 
Job  service  times  which  are  mutually  independent,  and  one 
server.  In  addition  to  processor-sharing  mode,  we  assume 
that  the  system  is  work- con  so rv inn  .  i.e.  that  preemption 
and  resumption  of  a  job  will  not  require  additional  service 
time.  In  sum,  we  model  a  time-sharing  computer  facility  as 


a  work-conserving,  processor-sharing  M/G/1  queuing  system 
driven  by  a  policy  function  F(a). 
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When  a  job  arrives  at  the  system,  it  adds  its  service 
time  to  the  unfinished  work .  the  work  (in  units  of  service 
time)  which  the  system  has  yet  to  perform  on  resident  jobs. 
Between  job  arrivals,  the  unfinished  work  decreases  in  time 
at  unit  rate  until  it  reaches  zero.  Thereafter,  the  system 
i 3  free  of  jobs,  the  unfinished  work  remains  zero,  and  the 
system  is  said  to  be  idle  until  the  next  job  arrives.  At 
this  epoch  the  unfinished  work  jumps  to  the  value  of  the 
next  job's  service  time.  It  will  then  decrease  linearly 
until  either  another  job  arrives  or  the  job  is  serviced  to 
completion,  whichever  occurs  first.  Periods  during  which 
the  unfinished  work  is  positive  are  called  busy  periods .  In 
equilibrium,  every  busy  period  is  followed  by  an  idle  period 
and  vice  versa.  For  our  analysis,  we  shall  study  the  system 
over  a  large  number  of  such  periods  until  equilibrium  is 
reached  . 

We  begin  to  observe  the  system  at  the  beginning  of  an 
arbitrary  busy  period  at  time  zero  and  number  jobs  in  the 
order  of  their  arrival  (Jr0,1,2,  ...  ).  Their  arrival 
epochs  and  service  time  r equ 1 r omen t a  will  be  denoted  by  the 
random  variables  lj  and  Sj  respectively  (To=0).  Ij  stands 
for  the  time  between  the  arrivals  of  jobs  j-1  and  j,  i.e. 
Ij  =Tj  -Tj-i  ( j=  1  , 2 ,  ...  ).  We  express  delays  and  other 
random  variables  of  interest  for  a  particular  (but 
arbitrary)  Job,  say  Job  number  n,  and  refer  to  this  Job  as 
the  test  ,1ob .  Introducing  special  symbols  for  its  arrival 
epoch  t=Tn  and  its  service  requirement  x=Sn, 


we  denote  its 


t 
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residence  time  in  the  system  (the  time  between  arrival  and 
departure)  by  R(t,x).  This  residence  time  consists  of  the 
test  job's  service  time  x  and  its  waiting  time  W(t,x): 

R( t  ,x)  =  W( t  ,x)  +  x .  (3) 

It  often  proves  advantageous  to  relate  the  waiting  time  of  a 
job  to  the  amount  of  service  (work)  performed  on  other  jobs. 

With  this  method,  the  author  [9]  obtained  considerably 
simplified  derivations  of  the  response  functions  of  such 
algorithms  as  the  processor- sharing  round  robin  and  feedback 
schemes.  Using  this  approach,  we  distinguish  between  two 
groups  of  jobs:  the  early  arrivals  (j<n)  which  arrive 

before  the  test  job  and  the  late  arrivals  (j>n)  which  arrive 
after  it.  We  define  the  early  work  V£(t,x)  (late  work 
VL(t,x))  as  the  total  service  performed  on  all  early  (late) 
arrivals  during  the  test  job's  residence  time.  Clearly,  an 
early  arrival  which  departed  prior  to  the  test  job's  arrival 
at  time  t  cannot  benefit  from  the  early  work.  Similarly,  a 
Job  arriving  after  the  test  job's  departure  cannot 

contribute  to  the  late  work.  With  these  definitions,  s 

equation  ( 3 )  may  n e  rewritten  as 

R(t,x)  =  VE(t,x)+VL(t,x)  +  x.  (4) 

I 

! 

Note  that  the  residence  time,  the  ear1 y  work,  and  the  late 
work  are  stochastic  processes  defined  for  any  job  n 
(n  =  0,1,2,  ...  )  arriving  at  time  t  =  Tn  .  Equilibrium  values 


are  obtained  by  letting  n  (and,  thus,  t)  approach  infinity. 
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The  response  function  R(x)  can  now  be  expressed  as  the 
time  average  of  the  residence  time  in  equation  (4).  With 
the  definition  of  the  time  average  Q(x)  of  a  stochastic 
process  Q(t,x)  with  a  constant  parameter  x, 


Q ( x )  =  lim  (1/T)  f  E[Q(t,x)]  dt, 

T-*-0O  J 


we  obtain 


R ( x )  =  ( x )  +  VL(x)  x, 


Unfortunately,  the  early  and  the  late  work  processes  are  not 
Markovian.  However,  a  method  involving  a  further 
decomposition  of  the  earl.y  work  process  will  be  shown  to 
yield  to  an  analytical  treatment  for  all  policy  functions  of 
the  form  F(a)<a. 


The  significance  of  the  constraint  F(a)<.a  on  policy 
functions  deserves  some  attention.  Since  the  attained 
service,  a,  of  a  job  is  included  in  the  time  it  spent  in  the 
system,  r,  we  always  have  r-a_>0.  It  follows  from  equation 
(2)  and  F(a).<ln  that  a  job's  priority  cannot  be  negative, 
since  P(a,r)  -  r-F(a)  A  r-a  >  0.  The  priority  loss  due  to 
attaining  service  always  dominates  the  priority  gain  duo  to 
spending  time  in  the  system.  A  newly  arriving  job  has  zero 
priority  and  will  not  be  serviced  until  its  priority  becomes 
equal  to  that  of  the  highest  priority  job(s)  in  the  system. 
After  Joining  the  highest  priority  group,  a  job  will  remain 
in  the  highest  priority  group  until  it  departs.  The  policy 
function  scheduler  assures  this  by  processing  the  members  of 
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this  group  at  (possibly)  different  rates  [10].  Note  that 
jobs  join  the  highest  priority  group  in  the  order  of  their 
arrival.  Thus,  a  resident  job  is  either  waiting  with  no 
service  attained,  or  it  is  a  member  of  the  highest  priority 
group  and,  thus,  being  serviced.  Just  prior  to  its 
departure,  the  test  job  is  being  serviced  and  has  the  same 
(highest)  priority  as  all  early  arrivals  which  are  still 
resident.  Similarly,  all  resident  late  arrivals  which  have 
attained  any  service  at  all  also  have  this  same  highest 
priority.  These  properties  play  an  important  role  in  our 
derivation.  If  the  policy  function  is  not  constrained  by 
F(a)<a,  the  priority  of  the  highest  priority  group  may 
become  negative.  Thus,  a  new  arrival  with  zero  priority  may 
preempt  the  highest  priority  group.  Furthermore,  the 
priority  of  a  resident  early  arrival  may  be  lower  than  that 
of  the  test  job  when  the  test  job  departs.  In  this  paper, 
we  shall  adhere  to  the  constraint  F(a)^.a. 

In  terms  of  notation,  A  will  denote  the  job  arrival 
rate.  The  random  variable  S  and  the  functions  G  and  g  stand 
for  the  service  t  init:  requirement  of  a  job,  the  service  time 
distribution  function  and  its  probability  density  function 
respectively.  Gc  denotes  the  complement  of  G: 
Gc ( x ) = 1 -G ( x ) .  A  glossary  at  the  end  of  the  paper  summarizes 
the  symbols  and  notation  used  in  the  analysis.  It  also 
contains  a  useful  identity  for  the  moments  of  the  truncated 
service  time  S<x  ,  S<x  =min[ S , x ] ,  which  is  frequently  used  in 
the  derivation.  The  analysis  does  not  make  use  of 
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transform  3  and,  thus,  illustrates  the  physical  behavior  of 
the  system  in  time. 


of.  iue  earli  mm 


The  early  work  is  the  amount  of  service  which  early 
arrivals  (jobs  j<n)  attain  during  the  test  Job's  residence. 
Equivalently,  it  may  be  defined  as  the  service  which  early 
arrivals  attain  prior  to  the  test  job's  departure  minus  the 
service  they  attain  prior  to  its  arrival.  There  are  two 
types  of  early  arrivals:  those  which  are  serviced  to 
completion  and  exit  before  the  test  job  departs,  and  those 
which  are  still  resident  at  the  test  job's  departure  epoch. 
We  consider  the  latter  type  first. 


As  noted  in  the  preceding  section,  the  priority  of  the 
test  job  equals  that  of  the  resident  early  arrivals  at  the 
departure  epoch  of  the  test  job.  Thus,  with  aj  denoting  the 
attained  service  of  a  resident  job  j,  and  using  L=R(t,x)  for 
the  residence  time  of  the  test  job,  we  have 


P(I.,x)  ■  l.-F(  x )  =  L  +  t-Tj -F(aj  )  =  P  (  L+ t-Tj  ,  a  ;  )  . 


Note  that  Tj<t  =  Tn  since  j<n.  Solving  for  aj  ,  we  obtain 


aj  =  F_l(  F(  x )  +  t-Tj  )  , 


where  F-'  denotes  the  inverse  of  the  policy  function  F. 
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Equation  (7)  specifies  the  attained  service  aj  of  a 
resident  early  arrival  at  the  test  job’s  departure  epoch. 
Early  arrivals  of  the  other  type  will  already  have  departed 
after  receiving  their  service  requirement  Sj  .  However,  had 
the  service  requirement  Sj  of  such  a  departed  early  arrival 
been  larger  than  aj  ,  this  job  would  still  be  resident  with 
exactly  aj  seconds  of  attained  service.  Therefore,  anv 
early  arrival  will  have  attained  the  minimum  of  Sj  and  aj 
respectively  when  the  test  job  departs.  The  total  amount  of 
the  early  work,  which  is  to  be  performed  during  the  test 
job's  residence  time,  can  now  be  expressed  as  the  sum  of  the 
individual  minima  minus  the  service  performed  prior  to  the 
test  job's  arrival  at  epoch  t.  The  latter  is  simply  the  sum 
of  the  durations  of  all  busy  periods  up  to  epoch  t,  or  t-H , 
where  H  denotes  the  sum  of  the  durations  of  all  idle  periods 
preceding  t.  Thus,  we  have 

rt-l 

Vg-U.x)  =  minCSj  ,  F“*(  F(  x)  +  t-Tj  )]  -  (t-H).  (8) 

By  expressing  t  and  Tj  as  sums  of  interarrival  times  and 
subtracting  Sj  from  the  minima  we  get 

n~l  r  -I 

V£(t,x)  =  }  t  Sj  -Ij-H  ]  +  H  -  ^  max  [  0  ,  Sj -F_,(  F(  x )  +  t-Tj  )].  (9) 

F°  ■ j-o 

In  the  first  two  terms  of  equation  (9)  we  recognize  the 
expression  for  the  unfinished  work  U(t),  also  called  the 
virtual  delay  [11].  It  is  identical  to  the  actual  delay  of 
the  test  job  under  FIFO.  Naming  the  third  term  V^(t,x), 

n-J 

VA(t,x)  =  )  max  [  0  ,  Sj  -F_,(  F(  x  )  +  t-Tj  )], 


(10) 
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we  decompose  the  early  work  by  rewriting  eouation  (9)  as 

V£(t,x)  =  U(t)  -  VA(t,x).  (11) 

As  an  aid  to  intuition,  this  decomposition  is  depicted  in 
Figure  1.  Assuming  some  fixed  value  for  the  test  job's 
service  requirement  x,  Figure  l.a  illustrates  how  the 
minimum  in  equation  (8),  i.e.  the  attained  service  of  job  j 
at  the  departure  epoch  of  the  test  job,  is  obtained  via  the 
inverse  F-1  of  the  policy  function.  The  minima  of  four  jobs 
forming  the  first  busy  period  have  been  superposed  in  Figure 
l.b.  The  shaded  areas  represent  the  maxima  in  equation 
(10),  i.e.  the  individual  contributions  to  the  process 
VA(t,x).  Summing  up  the  individual  minima  and  subtracting 
the  work  t,  which  has  already  been  performed,  yield  the 
total  for  the  early  work.  Figure  l.c  shows  that  this  total 
is  identical  to  the  unfinished  work  U(t)  minus  the  work 
VA(t,x).  A  continuation  of  this  diagram  over  several  busy 
periods  consists  of  probabilistic  replicas  of  the  first  one 
separated  by  idle  periods. 

The  form  of  equation  (11)  suggests  that  the  time 
average  V£(x)  can  be  obtained  as  the  difference  of  the  time 
averages  U  and  VA(x).  However,  we  must  first  verify  that 
the  expression  for  VA(t,x)  does  not  cause  VE(t,x)  to  become 
negative.  In  that  case,  equation  (11)  would  have  to  be 
replaced  by  Vc ( t  , x ) = raaxf 0 , U ( t ) - VA ( t , x ) ) ,  since  the  early 
work  is  a  nonnegative  process  with  busy  periods  defined 


analogously  to  those  of  the  unfinished  work.  However,  the 


(a)  Contribution  of  job  j  to  the  early  work  VE(t,x) 


(c)  The  difference  between  unfinished  and  earlv  work 
Figure  1.  Decomposition  of  the  early  work. 
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already  adopted  constraint  on  the  policy  function,  F(x)<.x, 
also  assures  the  positivity  of  V£(t,x)  throughout  any  busy 
period  of  U(t).  This  is  no  coincidence.  Since  this 
constraint  assured  a  nc  i-preemptive  mode  of  operation,  a 
test  Job  which  arrives  during  a  busy  period  and  has  a 
non-zero  service  requirement  must  always  wait  for  some  work 
to  be  done  on  resident  early  arrivals,  i.e.  V£(t,x)>0.  We 
formalize  this  result  in  the  following  theorem. 

Theorem :  The  busy  periods  of  the  processes  U(t)  and 
V£(t,x)  are  identical  for  all  positive  values  of  t  and  x  if 
and  only  if  F(x)_£x. 

Proof :  By  definition,  the  early  work  is  a  subset  of 
the  unfinished  work  and,  thus,  a  busy  period  of  the  early 
work  cannot  be  longer  than  the  corresponding  busy  period  of 
the  unfinished  work.  It  could  be  shorter  though.  On  the 
other  hand,  equation  (11)  shows  that  V£(t,x)  cannot  become 
zero  (and  terminate  its  busy  period  before  U(t)  does)  as 
long  as  U(t)>VA(t,x).  The  expressions  for  U(t)  and  VA(t,x) 
are  given  in  equation  (9).  Since  all  busy  periods  are 
probabilistic  replicas  of  each  other,  we  limit  our  attention 
to  a  single  one,  say  the  first  one,  and  set  H=0.  A 
sufficient  condition  for  U(t)>VA(t,x)  is  obtained  by 
requiring  the  individual  j-terms  in  equation  (9)  to  be 
positive : 

Sj  -Ij+I  >  Sj  -F~'(F(x)  +  t-Tj  )  ,  0<Jln-1. 
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After  cancelling  Sj  and  expressing  t-Tj  as  a  sum  of 
interarrival  times,  this  condition  can  be  rewritten  as 

Ij-H  ^  F  (  F(  x)  +  Ij  +  |  +  Ij+£  +  ...  +In)  . 

Clearly,  the  constraint  F(x)<.x  assures  this  sufficient 
condition  for  all  x>0.  If  n=1,  j  assumes  only  the  value  0, 
and  the  j-term  with  j  =  0  is  identical  to  U ( t) -VA ( t  ,x )  .  This 

special  case  shows  that  the  constraint  F(x).£x  is  not  only  a 

sufficient,  but  also  a  necessary  condition  for  the  identity 
of  the  busy  periods  of  U(t)  and  V^(t,x). 

With  the  positivity  of  equation  (11)  assured  throughout 
any  busy  period,  the  time  average  of  the  early  work  is 
indeed  the  difference  of  the  time  averages  for  U(t)  and 
VA(t  ,x)  : 

Vc  ( x )  s  U  -  V.  ( x )  .  (12) 

The  time  average  of  the  unfinished  work  is  well-known  (see 

Wolff  [11]  for  a  derivation  which  does  not  use  transforms), 

U  =  AKSi/l’(1-j) 

where  j>=AKS  denotes  the  system  load,  and  ( x )  is  defined  by 
equation  (5  )  : 


T 


VA(x) 

=  lim  (1/T)  f 
T-co  i 

EV^(t,x)  dt. 

(13) 

For  Poisson 

arrivals,  the 

contributions 

of  the 

various 

arrivals  to 

EVA(t,x)  are 

equal  to  the 

integral 

of  the 

expected  contribution  of  a  job  arriving  at  epoch  |  times  the 
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probability  of  the  occurrence  of  such  an  arrival.  From  the 
definition  of  V^(t,x)  in  equation  (9)  we  get 

t  00 

EVA(t,x)  -Jf  [s-F-'(F(x)*t-j)J  g(s)  ds  Adj. 

Before  this  expectation  can  be  substituted  in  equation  (13) 
to  obtain  the  time  average,  the  lower  integration  boundary 
for  ^  must  be  adjusted.  If  the  policy  function  F(x)  assumes 
a  finite  value  for  x-*~oo,  the  inverse  F''(  F(  x)  +  t-^ )  is  not 
defined  for  arguments  larger  than  F(oo).  In  that  range,  the 
flatness  of  the  policy  function  prohibits  contributions  of 
arrivals  which  occured  too  far  in  the  past.  Thus,  the  lower 
boundary  0  should  be  replaced  by  max[ 0 , F( x ) + t-F( 00 ) ]  to 
handle  the  two  cases  of  finite  and  infinite  values  of  F(oo). 
However,  by  solving  the  two  cases  separately,  it  can  be 
shown  that  the  two  boundaries  max[ 0 , F( x ) + t~F( CO ) ]  and 
F(x)  +  t-F(Oo)  are  interchangeable  under  the  limit  of  equation 
(13).  Chosing  the  simpler  boundary,  we  have 

T  *  00 

Vf  (x)  -  1  i in  ( a  / T )  !  j  j  [  s-F“'(  F(  x )  +  t-  I; )  3 g(  s)  d sd*F ;dt . 

o  t  •  I  (?■)  f) 

Substituting  y  =  F"'(  F(  x)  +  t-J )  and  evaluating  the  innermost 
integral  yield 

T  00 

VA(x)  =  11m  (A/T)  f  f  F’(y)[ES-ES<v]  dy  dt 

T*w  0  l 

and  the  final  expression  is  obtained  by  taking  the  limit  and 
integrating  by  parts: 
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co 

VA(x)  =  -XF(x)[ES-ES<x]  ♦  A  J  F(y)GC(y)  dy.  (1H) 

x 

I 

Rather  than  deriving  this  time  average  from  the 
defining  equations,  the  method  of  triangular  arrays  [ 4 ]  can 
j  be  adopted.  Starting  from  the  definition  of  V^(t,x)  in 

equation  (10),  we  get 

oo 

VA(x)  =  A  j  E[max[0 , S-FH( F( x)+t) )]  dt. 

I  ° 

Again,  the  upper  integration  boundary  must  be  adjusted  to 
handle  finite  values  of  F(oo).  We  replace  it  by  F(oo)-F(x) 
to  handle  the  general  case.  Substitution  of  y=F(x)+t  yields 


o 


** 

X 

II 

E[ max[ 0 , S-y )  ]  F 

'(y)  dy, 

.  and  expressing  the 

expectation  of 

the  maximum 

as 

ES-ES,  . 

followed  by  an 

integration  by 

parts  results 

in  the 

expression  given  by 

equation  ( 1 H ) . 

This  method 

offers  an 

intuitive  interpretation.  Each  job  contributes  a  certain 
area  (the  shaded  area  in  Figure  1)  to  VA(t,x).  The  time 
average  V^(x)  is  simply  the  expected  value  of  this 
contribution  multiplied  by  the  arrival  rate  (the  number  of 
contributions  per  unit  time). 

3_l  HUS.  LAIS  MM  PB.QCSS.S 

The  lat"  work  is  the  amount  of  service  which  jobs 
arriving  after  the  test  Job  will  attain  during  the  test 
Job's  residence  time.  Together  with  the  early  work,  it 
represents  the  delay  encountered  by  the  test  job.  Recall 


1 
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that  the  teat  job's  priority  remains  non-negative  for  policy 
functions  of  the  form  F(x)i.x  and  that  the  initial  priority 
of  an  arriving  Job  is  zero.  To  attain  its  first  service 
allocation,  a  late  arrival  must  gain  priority  by  waiting 
until  it  catches  up  with  the  highest  priority  group. 
Thereafter,  it  will  remain  in  the  highest  priority  group 
until  it  departs. 


Similar  to  the  approach  used  to  determine  the  early 
work,  we  shall  relate  job  priorities  at  the  departure  epoch 
of  the  test  job  in  order  to  determine  the  late  work. 
Assuming  again  that  the  test  job  n  remains  in  the  system  for 
L  seconds  and  that  its  service  requirement  is  x  =  Sn,  we 
observe  a  job  j>n  which  arrives  i  seconds  after  the  test  job 
(i<L)  and  attains  A  seconds  of  service  by  the  time  the  test 
job  departs.  Note  that  a  late  arrival  will  attain  no 
service  at  all  unless  it  catches  up  with  the  highest 
priority  group.  Equating  the  priorities  of  the  test  job  and 
a  resident  late  arrival, 


P ( L ,  x )  =  L-F(x)  =  L-J-F(A)  =  P(L-i,A), 


wc  obtain  the  amount  of  attained  service  as 


A  =  F"'(F(x)-i). 


(15) 


| 

For  A  to  be  positive,  i.e.  for  the  late  arrival  to  catch  up 
with  the  highest  priority  group  before  the  test  job  exits,  i 

must  be  less  than  F(x).  Thus,  no  job  arriving  F(x)  seconds  i 

1 

V 

after  the  test  Job  will  receive  any  service  during  its  J 
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residence  time  L.  Note  that  the  constraint  F(x)j£x  assures 
that  L  is  not  less  than  F(x),  since  the  test  job's  residence 
time  L  cannot  be  shorter  than  its  service  requirement  x. 
Consequently,  there  exists  a  deterministic  upper  bound  F(x) 
on  the  interval  during  which  late  arrivals  may  occur  and 
still  get  serviced  to  some  degree.  This  implies  that  the 
late  work  does  not  depend  on  the  early  work  which  the  test 
job  encounters! 

Departures  of  late  arrivals  are  handled  like  those  of 
early  arrivals.  If  a  late  arrival  departs  before  the  test 
job,  its  service  requirement  S  must  have  been  less  than  the 
value  of  A  in  equation  (15).  Thus,  any  late  arrival  will 
contribute  min[S,A]  to  the  late  work,  provided  it  arrives 
within  F(x)  seconds  after  the  test  job's  arrival.  Making 
use  of  Poisson  arrivals,  the  expectation  of  the  sum  of  the 
contributions  of  the  late  arrivals  may  again  be  replaced  by 
an  integral.  The  time  average  for  the  late  work  therefore 
amounts  to 

ft V) 

V(  (x)  =  j  R[  mini  S  .  F~'(  F(x)-l)]]  Xdi. 

o 

Expressing  the  expectation  of  the  minimum  in  terms  of  the 
expectation  of  the  truncated  service  time,  we  have 

F00 

VL(x)  =  X  ^  ES<F-'(F(x')_i. )  di. 

o 

Substituting  y  for  F_,(F(x)-i)  and  integrating  by  parts  yield 


the  final  expression 
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X 

VL(X)  =  AF(x)ES<x  -  A  J  F(y)Gc(y)  dy.  (16) 

0 

It  is  quite  common  among  scheduling  algorithms  that  the 
expressions  for  the  early  and  the  late  work  are  more 
complicated  than  the  response  functions  themselves.  The 
class  of  policy  functions  F(x)<.x  is  no  exception.  We 
proceed  by  presenting  the  overall  result. 
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JLt  PROPERTIES  ££  RESPONSE  FUNCTIONS 

With  the  time  averages  for  the  early  and  the  late  work 

established,  we  obtain  the  response  function  from  equation 

(6)  by  substituting  equations  (12),  (14),  and  (16)  and  using 

the  symbol  g  for  the  load  AeS: 

oo 

R(x)  =  U  -  A  J  F(y)Gc(y)  dy  ♦  j>F(x)  +  x.  (17) 

0 

This  result  is  valid  for  work-conserving,  processor-sharing 
M/G/1  systems  driven  by  arbitrary  policy  functions  whose 
normalized  equivalents  satisfy  the  constraint  F(x)^.x.  The 
average  waiting  time  W(x)  of  a  job  with  a  service 
reqnl  rcrnr-nl  of  x  seconds  In  equal  to  W(x)  =  R(x)-x: 

f?'l 

W (  x )  =.  U  -  A  j  F  (  y ) G f  (  y )  d y  +  <> F (  x )  .  (18) 

0 

Note  that  only  the  last  term  is  a  function  of  x.  The  first 
two  terms  are  constant  and  have  the  value  W(0).  Thus,  the 
shape  W(  x ) -W(  0 )  =j?F(  x)  of  the  average  waiting  time  is 
independent  of  the  shape  of  the  service  time  distribution; 
in  fact,  it  is  simply  the  policy  function  multiplied  by  the 
load  p.  The  values  of  W(0)=R(0)  have  bounds  determined  by 
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the  constraint  0<.F(x)<.x.  By  evaluating  equation  (18)  for 
x=0  and  the  policy  functions  F(x)=0  and  F(x)=x  these  bounds 
can  be  expressed  in  terms  of  the  average  waiting  time  U  of 
the  FIFO  algorithm: 

J3U  <  R  ( 0 )  =  W(0)  1  U. 

The  lower  bound  is  obtained  with  F(x)=x  which  tends  to 


increase  the  response  of  long  jobs.  Conversely,  F(x)=0,  the 
FIFO  algorithm,  maximizes  the  response  for  short  jobs  and 
favors  long  jobs. 

Using  the  overall  average  residence  time  R  as  a 

performance  criterion,  where  R  is  defined  as 
oo 

R  =  J  R ( x )  g ( x )  dx, 

0 

the  optimal  form  of  F{x)  can  be  determined  as  a  function  of 
the  service  time  distribution  by  minimizing  R.  From 

equation  (17)  we  obtain 

oo  oo 

R  =  U  +  ES  -  At  J  F(y)G°(y)  dy  -  ES  J  F(x)g(x)  dx] . 

0  0 

Noting  that  only  fist*  term  having  brackets  involves  the 
policy  function  F,  we  call  this  term  -A[M]  and  attempt  to 


maximize  M.  For  the  policy  function  F(y)  we  substitute  an 


integral  over  its  derivative  and 

integral  in  M  by  parts  to  get 

oo  y 

M  =  j~  j'  F  ’  (  x )  dx  Gc  (  y )  dy  -  ES 


integrate  the  second 


oo 

J  F' ( x ) Gc ( x )  dx  . 

o 


Finally,  reversal  of  the  order  of  integration  of  x  and  y 
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yields  the  expression  to  be  maximized: 

OO  CO 

M  =  J  F ' ( x)  [  j"  Gc(y)dy  -  ES  GC(x)  ]  dx.  (19) 

o  i 

The  bracketed  term  plays  an  important  role  in  reliability 


theory  [2].  It  is  used  to  characterize  the  distribution 
function  G  of  a  random  variable  S  with  respect  to  its 
residual  life  [53.  In  particular,  a  distribution  function  G 
is  said  to  be  g -MRLA  (^/-MRLB)  ,  i.e.  it  has  its  mean 


residual  life  bounded  above  (below),  if  and  only  if 
oo 


J  Gc(y)  dy  ft"  °C  (x>  * 
x 

The  mean  residual  lives  of  a  large  class  of  distributions 
are  bounded  with  respect  to^=ES.  For  ES-MRLA  distributed 
service  times  S,  it  follows  from  equation  (19)  that  F'(x)=0, 
i.e.  F( x ) =0  or  FIFO,  maximizes  M  and  thus  minimizes  the 
average  overall  residence  time.  This  is  not  surprising 
since  Wolff  [12]  established  the  superiority  of  FIFO  over 
both  the  round  robin  and  the  feedback  algorithms  for  the 
more  general  work~con3erv ing  G/G/1  systems.  Consider  the 
case  when  the  service  time  is  not  ES-MRLA  distributed. 
Since  f'(x)  need  not  be  continuous,  the  derivative  F'(x)  may 
contain  Dirac  pulses.  Then,  the  optimal  policy  function  can 
be  obtained  from  equation  (19)  via  simple  optimization 
techniques  [1],  It  i3  not  difficult  to  show  that  optimal 
policy  functions  satisfying  the  constraint  F(x)^,x  consist  of 
sequences  of  a  constant  portion,  a  jump  to  the  identity 
function,  and  a  portion  equal  to  the  identity  function.  As 


an  example,  the  composite  policy  function  in  Figure  4  (to  be 
discussed  later)  illustrates  such  an  optimal  policy  function 
consisting  of  a  single  sequence  of  the  three  portions. 

Returning  to  the  expression  for  the  response  function 
in  equation  (17),  we  note  that  it  may  oe  viewed  as  a 
transformation  of  policy  functions  into  response  functions. 
The  inverse  transformation  is  obtained  by  a  simple 
differentiation  and  the  application  of  the  boundary 
condition  F(0)=0  for  normalized  policy  functions: 

F(x)  =  [R(x)  -  x  -  R(0)]  / 

Of  course,  not  any  arbitrary  response  function  can  be 
obtained  by  a  policy  function.  First  of  all,  we  are  limited 
by  the  constraint  F(x)j$.x  which  implies 

R  (  x )  <.  R  ( 0  )  +  x  (  1  +£ )  . 

But  there  are  at  least  three  more  constraints  which  are 
generally  valid  for  any  scheduling  algorithms  which  base 
their  priorities  solely  on  attained  service  time  and  time  in 
system.  First,  the  rcsloensc  time  cannot  be  smaller  than 
the  service  time  which  it  includes: 

R  (  x )  2  x  . 

Second,  an  intrinsic  constraint  on  response  functions, 
regardless  of  the  scheduling  algorithms  used,  limits  the 
discriminatory  treatment  of  short  jobs  versus  long  jobs. 
This  constraint  is  referred  to  as  a  conservation  law 
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t  5  ,  P .  1 97  ]  : 

oo 

1 RU>  °c  (x)  dx  =  ES2/2(1-j>).  (20) 

o 

Since  the  integral  of  the  response  function  weighted  by  the 
(decreasing)  complementary  distribution  function  must  be 
constant,  a  favorable  treatment  of  short  jobs  (small  R(x) 
for  small  x)  implies  delays  for  long  jobs  and  vice  versa. 
It  is  easily  checked  that  our  ~esult  in  equation  (17) 
satisfies  this  conservation  law.  Third,  tight  upper  and 
lower  bounds  [5,  p .  199]  have  been  established  on  response 
functions : 

AES2x/2  XES2/2  x 

-  +  x  <  R(x)  i.  -  +  - (21  ) 

1 - AES<X  (1-p)(1-AES<x)  1-AE3<X 

Applying  Little's  theorem  [7]  to  an  infinitesimally 
small  service  time  interval  dx,  .he  response  function  R(x) 
and  the  average  density  n(x)  of  resident  jobs  with  x  seconds 
of  attained  service,  can  be  related  [5,  p.164]: 

n(x)  =  AR'(x)  Gc(x). 

A  substitution  of  the  derivative  R'(x)  from  equation  (17) 
yields 

n(x)  =  X[1+j>F' (x)]Gc(x)  +  AR(0)<J(0)  ,  (22) 

where  the  Dirac  pulse  £(0)  denotes  a  unit  mass  at  the 
origin.  The  steeper  the  policy  function  is  for  a  given 


attained  service  x,  the  more  jobs  on  the  average  will  be 
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found  with  that  much  service  attained.  This  result  i3 
corroborated  by  the  fact  that  the  service  rate  of  a  job  with 
x  seconds  of  attained  service  is  inversely  proportional  to 
F* (x)  [ 10] . 

A  variety  of  performance  criteria  may  be  obtained  from 
the  average  density  of  resident  jobs.  The  integral  of  n(x) 
over  x  from  zero  to  infinity  yields  the  average  number  N  of 
jobs  in  the  system.  Clearly,  the  minimization  of  N  and  the 
minimization  of  the  overall  average  residence  time  R  result 
in  identical  policy  functions  since  N  =  Ar  [73- 
Discriminatory  policies  with  respect  to  the  treatment  of 
short  jobs  versus  long  ones  are  obtained  by  minimizing 
(maximizing)  the  integral  of  the  average  density  over  a 
specified  range  of  attained  service.  Of  course,  the 
conservation  law  in  equation  (20)  still  applies. 

Hu.  &E.££I£1£  fOLICX 

In  this  section  we  discuss  the  system  behavior 
resulting  from  linear,  exponential  and  composite  policy 
function?!.  While  the  response  functions  are  presented  for 
arbitrary  service  time  distributions,  exponentially 
distributed  service  times  have  been  assumed  for  the 
diagrams.  Note  that  the  mean  residual  life  of  an 
exponentially  distributed  service  time  is  equal  to  its  mean. 
Consequently,  the  terra  M  in  equation  (19)  is  zero 
independent  of  the  shape  of  the  policy  function  and  the 
overall  mean  residence  time  is  equal  to  FIFO's. 


The  response  function  resulting  from  a  linear  policy 


function  F(x)=Cx,  where  C  is  a  constant,  is  given  by 

R  (  x )  =  U  -  A  E  S2  C  /  2  +  x  (  1  C )  .  (23) 

Note  that  it  is  linear  in  x  and  that  it  depends  only  on  the 
first  two  moments  and  not  on  the  shape  of  the  service  time 
distribution.  Due  to  our  constraint  F(x)^.x,  the  validity  of 
equation  (23)  is  limited  to  CjL1  .  Thus,  FIFO  which  is 
defined  by  C=0  is  included.  The  response  functions  for 


C=0 ,.4,1 

are 

shown 

in 

Figure 

2  for  an  M/M/1 

system  with  a 

load  of 

75%. 

It 

is 

easily 

shown  that 

the  value  of 

R(ES2'/2ES)  is  independent  of  C  (ES2'/2ES  is  the  mean  residual 
life  of  the  service  time  S) .  Although  policy  functions  with 
C> 1  are  not  covered  by  our  result,  it  is  known  that  the 
feedback  scheme  is  defined  by  C-*-  oo  [10].  Its  response 
function  [5  ,  p  .  174  ]  , 

R (  x )  =  x/(1-AES<k)  +  XESjx/2(  1-XES<>C  )  , 

is  also  depicted  in  Figure  2.  Varying  C  from  0  to  oo  ,  we 
note  that  a  breakpoint  occurs  at  C=1  whr»ro  the  response 
function  loses  its  linearity  and  its  invariant  value  at 
x=ESz/2ES.  The  intuitive  explanation,  namely  that  the 
breakpoint  separates  the  non- preemptive  from  the  preemptive 
algorithms,  has  been  provided  by  our  theorem. 

It  is  instructive  to  compare  the  linear  policy  function 
algorithms  (linear  policies)  with  the  selfish  scheduling 
algorithms  [5,  p . 1883 .  In  these  algorithms,  all  jobs  in  the 


C=oo  (processi 
sharino 
feedbacl 


pol i cy 

function 

F(x)=Cx 

M/M/1 

r*  75 


or 

kl 


ES=1 
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system  are  divided  into  two  groups:  those  in  a  "queue  box" 
waiting  for  service,  and  those  in  a  "service  box"  sharing 
the  facility  according  to  a  given  algorithm  which  is 
referred  to  as  the  raw  scheduling  algorithm.  An  arrival 
enters  the  queue  box  where  its  age  (a  numerical  value) 
increases  from  zero  at  rate  o< .  Similarly,  the  age  of  a  job 
in  the  service  box  increases  at  rate  fl,  where  A  job 

passes  from  the  queue  box  to  the  service  box  when  its  age 
equals  that  of  the  jobs  in  the  service  box.  When  round 
robin  and  feedback  algorithms  are  used  as  the  raw  scheduling 
algorithms,  the  selfish  round  robin  (SRR)  and  the  selfish 
feedback  (SFB)  algorithms  result.  Linear  policies  and  SFB 
cover  a  (different)  continuum  of  algorithms  ranging  from 
FIFO  to  feedback  by  varying  C,  0<.C<00,  and  Q/c(,  12.  p>/&  2.0 ,  jf 

respectively.  But  while  SFB  permits  preemption  of  the 
highest  priority  group  by  a  new  arrival  throughout  the 
entire  range  except  for  {$>/&=  1,  linear  policies  are 


non- preempt  i  /e 

for 

C<.1  .  Interestingly, 

the  response 

functions  in 

tills 

non-preemptive 

range 

are  identical 

to 

those  of  SR  ft 

w  1  I.  h 

12  /$/K  2^/(  1^') 

Of 

course,  SRR 

i  s 

non-preemptive  and  approaches  the  round  robin  algorithm  with 
p/C/->-0 .  The  linear  policies  thus  form  a  hybrid  between  SFB 
and  SRR.  Furthermore,  a  linear  policy  with  parameter  C  may 
itself  be  used  as  the  raw  scheduling  algorithm  for  a  selfish 
scheduling  system  with  parameters  c*  and  /3,  thus  defining  a 
selfish  linear  policy.  As  it  turns  out,  such  a  selfish 
linear  policy  with  parameters  cx  ,  A,  C^.1  results  in  a 


response  function  identical  to  that  of  a  linear  policy  with 
parameter  C(l-^/c<).  It  can  be  shown  that  there  is  a  good 
reason  for  this  identity;  the  two  algorithms  are  actually 
equivalent . 


Next  consider  the  class  of  exponential  policy  functions 
with  F(x)  =  C[  l-exp(-kx)  ]  .  From  the  constraint  F(x)^.x  we  have 

Ck.<1  and  equation  (17)  becomes 

00 

R(x)  =  U  +  AC J exp( -ky )GC ( y ) dy  +  x  -  ^Cexp(-kx). 

O 

The  forms  of  the  response  functions  for  k=1/3  and  C=0,2,3 
are  given  in  Figure  3  Cor  a  75$  loaded  M'M/1  system.  The 
density  can  be  obtained  from  equation  (22): 

n(x)  =  At  1+^>kCexp(-kx)  }Gc(x)  +  AR(0)<f(0). 

The  expression  in  brackets  demonstrates  that  these 
exponential  policies  tend  to  keep  waiting  those  jobs  with 
little  attained  service.  Holding  kC  constant,  this  tendency 
can  be  weakened  by  choosing  a  smaller  value  of  k. 


The  i>oJLiax  funs U ana  of  the  form  F(x)~0  for 

x<m  and  1(x)  =  k  for  x2.m  are  representative  of  the  set  of 
optimal  policy  functions  which  are  obtained  by  minimizing 
the  average  overall  residence  time.  The  corresponding 
response  functions, 


R(x) 

are  depicted 


co 


tn 

in  Figure  ^ 


GC(y)  dy  +  F  (  x  ) 
for  m  =  0 , 1  ,  2  and 


+  x, 

an 


M/M/  1 


system 
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with  a  load  of  75J.  The  jump  of  the  response  function  at 
the  value  m  of  the  service  time  is  reminiscent  of  the  jump 
resulting  from  the  2-level  feedback  algorithm  [9].  This 
similarity  does  not  come  as  a  surprise  when  one  considers 
that  the  defining  policy  function  for  2-level  feedback 
algorithms  is  given  by  F(x)  =  0  for  x<m  and  F(x)=z  for  x  _>m , 
where  OO  [10].  This  (infinite)  step  function  is  itself 
closely  related  to  a  composite  policy  function.  However, 
due  to  its  height,  it  is  not  covered  by  our  analysis  which 
is  constrained  to  functions  of  the  form  F(x)<x.  The 
difference  between  the  two  algorithms  can  be  explained  in 
terms  of  the  derivatives  of  their  policy  functions.  A 
detailed  discussion  of  policy  function  derivatives  and  their 
relation  to  processing  rates  is  contained  in  [10). 

Due  to  the  parameters,  each  of  the  linear,  exponential, 
and  composite  policies  represents  a  (different)  continuum  of 
scheduling  algorithms.  In  each  case,  the  continuum  includes 
F(x)=0  (FIFO)  and  F(x)=x.  Linear  policies,  F(x)=Cx,  cover 
this  range  with  C  varying  from  0  to  1.  Exponential 
policies,  F( h )  2 XI  1  exp( - k* ) ) ,  have  two  parameters,  C  and  k. 
C  =  0  results  in  FIFO.  For  Ck=  1  ,  the  limit  of  k-*~0  approaches 
F(x)sx.  Composite  policies,  F(x)=0  for  x<m  and  F(x)=x  for 
x>.m ,  cover  FIFO  through  F(x)  =  x  when  m  is  varied  from 
infinity  to  zero.  The  choices  of  a  particular  policy  and 
its  parameter(s)  should  be  guided  by  some  optimization 
criterion  and  will  strongly  depend  on  the  given  service  time 
distribution.  Current  practice  often  ignores  the  dependence 


1  -  - 


Page  29 


of  response  on  the  service  time  distribution,  possibly 
because  of  the  lack  of  meaningful  measurements.  The  FIFO 
end  of  a  continuum  is  of  interest  for  ES-MRLA  distributed 
service  times  when  the  overall  residence  time  is  to  be 
minimized.  A  policy  close  to  F(x)=x  will  treat  short  jobs 
more  favorably.  Composite  policies  satisfy  both  of  these 
criteria  when  the  mean  residual  service  time  is  not  bounded 
above . 

The  validity  of  the  response  functions  in  equation  (17) 
is  limited  to  policy  functions  constrained  by  F(x)<.x,  but 
the  definitions  of  linear  and  exponential  policies  are  not. 
(Neither  is  the  definition  of  composite  policy  functions  if 
multiplied  by  a  constant  C.)  This  constraint  limits  the 
favorable  treatment  of  short  jobs  by  assuring  that  the 
priority  of  a  job  cannot  be  higher  than  that  of  an  earlier 
arrival.  Without  this  constraint,  the  degree  of 
discrimination  is  governed  by  the  conservation  law  in 
equation  (20)  and  the  bounds  in  equation  (21).  In  fact, 
linear  policies  result  in  the  most  discriminatory  scheduling 
algorithm  in  favor  of  short  jobs,  the  feedback  algorithm, 
when  the  slope  C  of  the  policy  function  approaches  infinity. 
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In  this  paper,  the  system  behavior  resulting  from  a 
broad  class  of  policy  functions  is  analyzed.  The  analysis 
is  based  on  a  work-conserving,  processor-sharing  M/G/l 
queuing  system  and  the  system  behavior  is  described  in  terms 
of  the  response  function.  To  provide  the  necessary 
background,  some  basic  properties  of  policy  functions, 
including  equivalence  and  normalization,  have  been  briefly 
reviewed.  Our  analysis  addresses  the  class  of  algorithms 
which  are  defined  by  F(a).<a,  where  the  parameter  a  of  the 
normalized  policy  function  F  is  the  attained  service  time. 
(Policy  functions  which  have  not  been  normalized  belong  to 
the  same  clas3  if  they  satisfy  F(  a)  <.F(0  )  +  a . )  The  main 
result,  equation  (17),  gives  the  response  functions  for  this 
class  of  algorithms.  As  expected,  these  response  functions 
satisfy  the  conservation  law  and  the  tight  bounds  which  have 
been  established  for  time-sharing  systems  [5].  Linear, 
exponential,  and  composite  policy  functions  are  presented  as 
examples  for  our  general  result.  Criteria  for  the  selection 
of  n  particular  policy  fur",  lion  are  also  discussed.  If  the 
overall  mean  response  time  is  used  as  a  performance  measure, 
it  is  shown  how  the  optimal  policy  function  can  be  obtained 
as  a  function  of  the  service  time  distribution.  Of  course, 
other  performance  measures,  like  the  average  number  of 
resident  jobs  with  less  or  more  than  a  certain  amount  of 
attained  service,  may  be  chosen,  but  the  closed  form 
expressions  of  our  results  permit  the  solution  of  a  variety 
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of  different  optimization  problems. 


The  derivation  of  the  response  function  involves  the 
non-Mar kovian  early  work  process.  Its  analysis  was 
simplified  by  a  decomposition  method  which  is  adaptable  to 
other  models.  Due  to  this  method,  the  derivation  does  not 
depend  on  the  use  of  transforms  and,  thus,  amplifies  the 
details  of  the  internal  system  behavior.  The  constraint 
F(a)<a  on  the  policy  functions  arises  from  a  comparison  of 
the  busy  periods  of  the  unfinished  work  process  and  the 
early  work  process.  Our  theorem  illustrates  how  the  notion 
of  preemption  can  be  related  to  the  busy  periods  of  these 
two  processes. 


The  mathematical  simplicity  of  the  main  result  is 
especially  appealing.  Nevertheless,  policy  functions  which 
are  not  constrained  by  F(a)<.a  should  be  analyzed  since  they 
behave  differently  with  respect  to  preemption.  Also,  the 
consideration  of  memory  requirements  in  the  definition  of  a 
policy  function  would  extend  the  applicability  of  the  model 
to  working  set  management  problems.  In  any  event,  the 
relationship  between  policy  functions  F(a)j<a,  service  time 
distributions,  and  system  response  has  been  established  and 
can  readily  be  used  to  optimize  the  response  with  respect  to 


a  given  performance  criterion. 


Page  32 


F  policy  function,  a  (weakly)  monotonic  increasing 

function  of  attained  service,  F(0)=0,  F  may  be 
discontinuous . 

F'  its  derivative,  a  non-negative  function  which  may 

include  Dirac's  delta  pulses. 

F-1  the  inverse  of  F.  For  constant  portions  of  F,  i.e. 

F(x)  =  c  for  y<.x<.z,  the  inverse  is  defined  as 
F“'(c)  =  z. 

EX,E[X]  the  expectation  of  a  random  variable  X. 

I  interarrival  time,  an  exponentially  distributed 

random  variable  having  mean  1/A. 

\  job  arrival  rate,  A  =1/EI. 

J  job  number,  j>.0  .  Jobs  are  numbered  in  order  of 

arrival . 

Ij  time  between  arrivals  of  jobs  j-1  and  J  ( ji.1  )  , 

I;  is  exponentially  distributed  with  mean  1/A. 

j- 

Tj  arrival  epoch  of  job  j,  Tj  =  Tj_t  +Ij  ,  T0  =0  ,  Tj=2_Ik» 

k=l 

S  service  time,  a  random  variable  with  distribution  G. 

Sj  service  time  requirement  of  job  j.  Sj  has 

distribution  G. 

G  cumulative  distribution  function  of  S , S j  . 

g  density  function  of  S  ,  Sj  ;  g(  s)  =  dG(  s) /ds  . 

g  may  include  Dirac's  delta  pulses. 

Gc  complement  of  G,  Gc ( s )  =  1 -G ( s )  ,  dGC ( s) /ds=-g( s) . 

S<x  truncated  service  time,  x=min[ S , x ] . 

n  job  number  of  the  test  job. 
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service  requirement  of  the  test  job,  x  =  Sn. 
arrival  epoch  of  the  test  job,  t=Tn. 
residence  time  of  the  test  job,  L=R(t,x). 
attained  service  of  a  resident  job  j<n  at  the  test 
job’s  departure  epoch. 

time  between  arrivals  of  the  test  job  n  and  a  late 
arrival  (a  job  j>n)  ,  i  =  Tj  -t. 

attained  service  of  a  resident  job  j>n  at  the  test 
job's  departure  epoch, 
system  load,  ^>  =  AES. 

unfinished  work  in  system  at  time  t,  a  stochastic 
process . 

time  average  of  the  unfinished  work  in  system, 


U=AES2/2( 1-j>) . 

R(t,x)  residence  time  of  the  test  job,  R(t,x)sW(t,x)+x. 
W(t,x)  waiting  time  of  the  test  job,  W( t ,x) =R( t ,x)-x , 
W(t,x)=VE(t,x)+VL(t,x) . 

VE(t,x)  early  work  encountered  by  test  job. 

VL(t,x)  late  work  eneountt.ed  by  test  job. 

V^(t,x)  difference  between  unfinished  work  and  early  work, 


V/  (t  ,x  )-U(  t)-V£(t  ,x)  . 

Q(x)  time  average  of  a  process  Q(t,x)  conditioned  on  x. 
Q  overall  time  average  of  process  Q(t,x). 

n(x)  average  density  of  jobs  with  x  seconds  of  attained 

serv ice . 


N 


time  average  of  number  of  jobs  in  the  system. 
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The  following  identity  for  the  m-th  moments  of  the 
truncated  service  time  can  be  derived  by  an  integration  by 
parts : 


x 


m 

ES<X  = 


smg(s)  ds  +  xmGC(x)  = 


J 


m-l  r 

ms  G  (  s)  ds . 


4  m  rn 

By  definition,  ES<X  =  ES0.  and  ES<X  approaches  ES  for  x-*-oo. 
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REALIZATIONS  OF  SEQUENTIAL  MACHINES 
USING  RANDOM  ACCESS  MEMORY 


Abstract 

Modem  large  scale  integration  techniques,  microcomputers, 
and  programming  techinques  have  made  the  classical  realizations 
of  sequential  machines  obsolete.  These  applications  of  sequential 
machines  all  occur  in  environments  where  random  access  memory, 
whether  read-only  or  writable,  is  an  extremely  cost  effective 
device.  This  paper  presents  a  realization  of  a  sequential  machine 
which  preserves  the  multiport  branching  characteristic  of  a 
sequential  machine.  A  structure  theory  and  a  design  technique 
are  presented  which  allow  an  optimal  memory  size  realization  to 


I.  INTRODUCTION 


Among  the  many  facets  of  system  design,  one  which  has  been  and  will 
continue  to  be  a  fruitful  area  of  study  is  the  implementation  of  control. 
Control  may  be  considered  on  various  levels.  Several  examples  are  micro¬ 
programmed  control  of  a  central  processing  unit,  microcomputer  control  of 
hardware  systems,  and  logical  control  of  programmed  systems.  This  paper 
examines  efficient  realizations  of  sequential  machines  implemented  as  • 

tables  stored  in  random  access  memory,  which  makes  application  to  any  or 
all  of  the  above  control  examples  possible. 

Sholl  [1]  has  studied  the  application  of  a  sequential  machine  to 
control  of  a  microprogram,  that  part  which  determines  the  next  address  of 
the  microprogram,  as  opposed  to  optimization  of  the  control  information 
field,  which  has  been  studied  by  Grasselli  and  Montanari  [2].  (Unfortunate¬ 
ly  the  word  control  is  used  at  two  levels  here  since  in  fact  we  are  dis¬ 
cussing  the  internal  control  of  a  microprocessor  which  in  turn  is  being 
used  to  control  the  larger  CPU.)  Sholl  developed  a  representation  of  a  sequen¬ 
tial  machine  used  in  place  of  the  conventional  next  address  field  and  branching 

operations  in  microprocessors  to  achieve  a  speed  advantage.  The  representa¬ 
tion  to  be  presented  here  fits  into  Sholl's  model,  retaining  the  speed 
advantage  but  having  different  implementation  and  memory  space  characteristics. 

A  rapid  rise  in  the  use  of  microcomputer  control  of  hardware  systems  is 
a  result  of  an  ever  decreasing  crossover  point  in  the  costs  of  microcomputers 
compared  to  TTL  controllers.  This  crossover  occurs  in  the  range  of  30  to  50 

m 

TTL  circuits  in  today's  technology  [3].  As  a  result,  the  predominant  users  of 
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microcomp uters  are  electronic  design  engineers  [4].  Therefore,  the  use 
of  sequential  machines  as  a  programming  technique  for  microcomputers  fits 
in  quite  well  with  the  backgrounds  of  the  typical  users.  Provision  of  a 
good  specification  language  and  an  automatic  optimizer  provides  a  "higher 
level  language"  with  inefficiency  problems  removed,  since  optimization  of 
a  sequential  machine  is  easier  than  compiler  code  optimization.. 

Many  authors  have  applied  sequential  machines  to  the  logical  control  of 
large  programs.  For  example,  Millenson  [5]  describes  their  application  to  the 
control  of  psychological  experiments.  The  realizations  considered  here  are 
applicable  to  such  programmed  control. 

The  problem  of  assignment  of  binary  variable  codes  to  the  internal 
states  of  a  machine  to  allow  its  realization  to  approach  some  measure  of 
optimality  has  received  considerable  attention,  especially  for  implementa¬ 
tions  using  combinational  circuits  and  Flip-Flops  [6]-[9l.  Sholl  [1]  intro¬ 
duced  the  use  of  memory  in  the  implementation  of  a  sequential  machine. 

This  paper  continues  the  investigation  of  the  use  of  memory  in  the 
implementation  of  a  sequential  machine,  but  with  a  representation  with  very 
different  properties  than  Sholl* s.  The  task  is  to  code  a  reduced  sequential 
machine  into  a  format  capable  of  being  loaded  into  a  random  access  memory. 

A  table  representation  will  be  used  since  tables  may  be  stored  in  random 
access  memories  efficiently. 

Figure  1  shows  a  conceptual  interpreter  and  table  implementation  of  a 
of  a  sequential  machine.  An  input  causes  the  present  state  to  be  read  from 
state  storage.  The  input  and  present  state  form  an  index  into  the  table 
containing  the  next-state  and  output  functions.  The  next-state  is  read 
from  the  table  and  written  into  state  storage,  while  the  output  is  used 
appropriately. 


In  Sholl's  realization,  the  interpreter  is  an  address  computation 
combinational  network,  with  state  and  input  as  network  inputs,  and  the 
address  of  the  next-state,  output  pair  as  the  network  output.  The  state 
assignment  has  an  effect  on  memory  redundancy  and  network  complexity. 

His  approach  sacrifices  a  small  amount  of  redundancy  in  order  to  achieve 
a  low  level  of  network  complexity.  This  is  done  by  using  a  "minimum  address 
variable  assignment",  which  has  one  table  entry  for  each  defined  state  table 
cell.  He  has  achieved  a  speed  advantage  over  programmed  or  microprogram 
branch  implementations  since  this  technique  may  be  considered  a  "multiport 
branch" [1]. 

The  method  considered  in  this  paper  decomposes  the  sequential  machine 
into  a  sub-table  per  input,  with  an  additional  table  of  pointers  to  these 
sub-tables.  Although  the  sequential  machine  is  reduced,  there  may  be 
pairs  of  states  with  identical  entries  in  a  single  input  sub-table.  In 
addition,  there  may  be  some  don't-care  entries.  It  is  assumed  that  the 
next-state  and  output  entries  are  either  both  don't-care  or  both  specified. 
Such  a  don't-care  occurs  when  the  input  is  externally  constrained  not  to 
occur  while  the  sequential  machine  is  in  a  particular  state.  The  output 
is  never  specified  without  the  next-state  since,  if  the  transition  can 
never  occur,  neither  can  the  output,  and  conversely,  if  the  transition 
occurs,  an  output  is  always  significant.  The  output  can  be  null,  or  no 
operation,  which  is  distinct  from  don't-care. 

Output  or  next-state  only  don't-cares  are  widely  treated  in  the  switch¬ 
ing  theory  literature.  However,  in  the  state  table  applications  mentioned 
above  and  others,  such  "don't-cares  were  not  used.  Since  these  single 
don't-cares  give  added  complexity  to  the  problem,  they  are  not  treated  here. 


If  the  input  is  known,  then  there  is  redundancy  in  the  information 
provided  by  the  state.  For  example,  it  is  never  necessary  to  identify  a 
state  whose  entry  is  don't-care,  nor  is  it  necessary  to  distinguish  between 
two  states  with  the  same  entries.  Providing  memory  locations  for  this 
redundant  information  is  wasteful.  A  state  encoding  scheme  that 
allows  identification  of  a  unique  entry  in  the  table  is  desirable.  That 
is,  the  original  sequential  machine  is  transformed  to  a  table  with 
only  one  occurrence  of  each  distinct  entry  in  each  input  sub-table. 

Consider  Figure  2.  The  input  sub-table  corresponding  to  input  1 
must  contain  four  entries,  one  for  each  of  1A,  3A,  5A  and  5B.  Similarly, 
the  input  4  sub- table  must  contain  two  entries.  The  state  number  no  longer 
provides  a  direct  index  to  the  sub-tables.  For  example,  if  the  machine 
is  in  state  7  and  input  1  is  received,  there  is  no  7th  entry  in  the  input 
1  sub-table.  A  mapping  algorithm  from  the  state  to  the  input  sub-table 
Indices  is  needed.  The  method  adopted  here  for  its  simplicity  of  use  is 
to  encode  the  states  using  binary  variables  y-jy2...yn  such  that  f°r  each 
input  there  exists  a  substring  of  these  binary  variables  which  can  be 
used  as  an  index  into  the  corresponding  input  sub-table.  Figure  3  shows 
an  appropriate  encoding  of  the  states  of  Figure  2.  Since  the  Ij  sub-table 
has  four  entries,  the  Ij  substring  should  have  four  distinct  codes,  which 
are  00,  01,  10,  and  11  under  variables  y^.  Note  that  the  *3  substrin9 
y^y2  has  exactly  three  values.  In  addition,  values  of  y^y2  for  any  two 
states  are  the  same  if  and  only  if  the  entries  of  those  two  states  are  the 
same  or  one  or  both  is  don't-care  under  input  2  in  Figure  2.  Thus  states  1 
and  4  have  the  y^y2  value  00.  Under  input  2  state  1  is  don't  care 
and  state  4  is  5A.  Figure  4  shows  the  tables  which  ultimately  realize  the 
machine  of  Figure  2. 


As  an  example,  consider  the  machine  to  be  in  state  5.  Thus  1010  is  in  the 
state  storage.  If  input  I2  is  received,  the  y^  variables  are  read  and  used 
to  index  the  ^  sub-table.  The  binary  10  is  equivalent  to  decimal  2, 
thus  2  is  added  to  the  sub-table  pointer  for  input  2,  and  TABLE  +6  is  read. 

The  entry  0001  A  is  the  encoding  for  4A,  which  is  the  proper  state  5,  input 
2  entry.  If  input  1^  is  received,  bit  y-j  is  1,  1  to  be  added  to  the  1^ 
sub-table  pointer,  TABLE  +11.  Thus,  TABLE  +12  is  read,  giving  1010  A,  which  • 
is  equivalent  to  5A.  In  each  case,  the  state  portion  of  the  entry  is  written 
in  its  entirety  back  into  state  storage.  The  output  might  be  the  address 
of  an  output  routine  or  an  index  into  a  branch  table,  etc.  The  assump¬ 
tion  made  here  is  that  the  interpreter  for  the  substring  encoding  is  either 

software  or  a  circuit  which  for  each  input  masks  the  appropriate  bits, 
shifts  them  to  the  right,  and  uses  them  as  an  index  into  the  sub-table.  By 
using  such  a  circuit  or  software,  there  is  less  custom  designed  circuitry, 
none  in  the  case  of  the  software  interpreter,  and  a  circuit  amenable  to 

possible  LSI  integration. with  only  the  final  mask  and  shift  quantities  to 
be  determined  for  the  individual  state  table,  perhaps  to  be  loaded  into  a 
Read  Only  Memory.  Figure  5  shows  a  possible  hardware  implementation,  while 
Figure  6  shows  a  PL/I  implementation.  Note  that  this  implementation  re¬ 
tains  the  same  "multiport  branch"  capability  as  the  Sholl  realization. 

A  technique  used  in  the  work  presented  here,  which  is  general  enough 
to  appear  applicable  to  other  problems,  is  the  method  of  treating  don't- 
care  conditions.  The  approach  followed  is  to  formulate  representations  of 
information  by  means  of  constructs  called  partitions-with-don't-cares 
(PDCs)  which  include  all  specified  information,  but  allow  nonspecified  in¬ 
formation  (don't  cares)  to  take  on  all  possible  values.  These  constructs  are 
constrained  to  be  compact  (nonenumerative)  and  to  possess  a  set  of  rules 
to  allow  enumeration  of  the  set  of  fully  specified  entitles  represented  by  the 
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construct.  Rules  are  also  provided  for  generation  of  such  constructs  by 
operations  on  other  such  constructs.  Such  a  technique,  if  utilized  fully, 
would  prevent  enumeration  as  a  synthesis  technique.  In  the  work  presented 
this  technique  is  extensively  used,  but  it  has  not  been  applied  to  all  the 
synthesis  steps. 

The  PDC  construct  is  used  throughout  the  synthesis  procedure.  In 
places,  operators  produce  only  a  single  PDC  as  a  result.  In  other  places, 
use  must  be  made  of  limited  enumeration.  These  techniques  make  possible 
the  optimization  of  larger  state  tables  by  a  programmed  version  of  the 
procedure  than  has  been  previously  reported.  A  program,  which  does  not 
yet  incorporate  all  the  features  of  the  procedure  presented  here  has 
successfully  optimized  a  9  state,  5  input  machine  in  2.3  seconds,  and  the 
7  state,  4  input  machine  shown  in  this  paper  in  1.5  seconds  in  an  IBM 
370/168. 

Introduction  of  all  the  features  presented  here  should  speed  it  up 
considerably.  This  program  does,  however,  contain  some  enumeration  prun¬ 
ing  techniques  which  are  not  presented  here  in  order  to  allow  a  sufficiently 
small  example  whose  solution  may  be  completely  described  to  serve  as  an 
expository  vehicle.  The  techniques  not  presented  would  not  prune  the 
present  example  to  any  significant  degree.  They  will  be  presented  in  a  sub¬ 
sequent  paper  dealing  with  such  techniques  for  computer  implementation  of 
the  synthesis  procedure. 


II.  PARTITIONS  WITH  DON'T-CARES 
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This  section  introduces  concepts  that  will  be  used  in  finding  the 
state  encoding  introduced  in  Section  I.  These  concepts  are  extensions  of 
partition  theory  [6],  and  with  which  reader  familiarity  is  assumed. 

Definition  1.  A  partition  with  don't-cares  (PDC)  of  a  set  S  is  a  collection 
of  disjoint  subsets  of  S  whose  set  union  is  S,  one  subset  of  which  is  dis¬ 
tinguished  and  may  be  empty. 

Conventions  used  in  denoting  PDCs  are  that  blocks 
are  enclosed  in  parentheses  and  the  distinguished  block  is  enclosed  in  <  >. 

For  example  (1 ,2)(3,5)(4,6)<7,8>  is  a  3-block  PDC  on  S  *  {1 ,2,3,4,5,6,7,8) 
with  a  distinguished  block  <7,8>  and  blocks  (1*2),  (3,5),  (4,6).  Blocks  of 
a  PDC  n  are  also  denoted  by  B^ir).  B^f*)  denotes  the  distinguished  block. 

A  PDC  with  an  empty  distinguished  block  is  a  partition.  #  (*)  is  the  number 
of  non-distinguished  blocks  in  it.  The  motivation  for  this  definition 
of  a  PDC  is  the  fact  that  many  problems  involving  don't-care  conditions 
Induce  equivalence  relations  on  sets,  with  the  exception  of  those  members 
of  the  sets  designated  by  don't-cares.  Since  a  true  partition  would 
specify  information  about  the  members  to  be  considered  don't-care,  it  is 
desirable  to  define  a  structure  with  the  ability  to  leave  some  elements 
unspecified.  Fur:  ore,  it  is  considered  that  the  equivalence  relation 

on  the  specified  members  of  the  set  determines  the  maximum  of  information  the 
PDC  should  generate.  That  is,  the  distinguished  block  is  to  be  treated  not  as 
a  true  block,  but  as  a  subset  which  may  be  distributed  arbitrarily  over  the 
specified  blocks.  Thus  the  PDC  n  in  reality  defines  a  set  of  partitions, 
denoted  by  G(»r),  generated  by  distributing  the. distinguished  block  over  the 


other  blocks  of  the  PDC  in  all  possible  ways. 


Definition  2.  A  PDC  is  less  specified  than  a  PDC  ir^  (ir^  ssir2)  if  and 

only  if 

1)  Each  nondistinguished  block  of  is  contained  in  a  nondistinguished 
block  of  u 2  and 

2)  Every  nondistinguished  block  of  ^  contains  exactly  one  non¬ 
distinguished  block  of  itj. 

Definition  3.  The  set  of  partitions  generated  by  it,  G(ir),  is 
{tJt  is  a  partition  and  ir  <st}. 

Thus,  if  ir.j  =  (1 ,4)(2)<3,5>  then  G(ir^)  is  the  set  of  partitions  (1 ,3.4,5) (2) , 
(1 ,4) (2,3,5 ), (1 ,3,4) (2,5) ,  and  (1 .4.5) (2,3) . 

In  general,  problems  with  don't-care  conditions  generate  PDCs  initially. 
Good  encodings  for  the  problem  under  consideration  can  then  be  achieved  by 
assigning  don't  cares  judiciously,  without  interfering  with  the  original  in¬ 
formation  content.  Thus  the  specification  ordering  gives  a  method  of  assign¬ 
ing  don't-cares  without  destroying  original  information.  If  w2  then 

6(^2)  c_  G(ir-| ).  Thus,  specifying  additional  elements  reduces  the  size  of  the 
set  generated. 

Definition  4.  The  relation  less  than  or  equal  to  holds  between  two  PDCs 
*1  and  ir2  (*i  s  *3)  ^  an<*  on^  ^  for  ever*y  B-f  (ir-j )  •  i  /  d,  there 
exists  a  Bj(ir2)  such  that  B^(w^)  £  Bj(ir2)  u  B^Ug),  and  2)  If  there  exists 
•  set  (Bj(ir2)|j  f  d  and  Bj(ir2)  £  8^(11^))  then  there  exists  a  set 
CB| («i ) I i  i  d  e:nd  B^(ir^)  £  B^fi^)}  of  equal  or  greater  cardinality  than 

<Bj(*2)>- 


If  the  and  irg  are  partitions,  this  definition  reduces  to  the  conven¬ 
tional  ordering  relation  between  two  partitions. 

The  following  theorems  show  that  s  ir2  if  and  only  If  in  the  sets 
GOrj)  and  G(tt2)  of  fully  specified  partitions  there  exists  at  least  one  pair 
(tj,t2),  c  G(hj)  and  x2  c  6(it2),  such  that  s  x2« 

Theorem  1  If  xj  and  x2  are  partitions  and  *.j  and  it2  are  PDCs  such  that 

T1  s  t2*  t1  c  and  t2  c  Gtir2^*  ^en  *1  s  *2 

Proof:  Condition  1 : 

*1  s  'l2  imPlles  that  for  every  B^(t^  )  there  exists  a  (x2)  such  that 
W  £  B^).  Therefore  B.^)  c  B^x,)  c  BjC^)  £  BJ^)  u  Bd(w2). 

Condition  2:  Consider B^)  c  Bd(ir1 ).  T]  s  x2  implies  that  for  every 

Bj(t2)  there  exists  a  B.fxj)  such  that  B^x,)  c  B^).  Then  B^Jc  B.fx,) 
£  Bj(x2)  £  Bj.(tt2)  u  Bd (xr2 )  c  B^)  u  Bd (xr2 ) .  Therefore  Bj(wj)  c  Bd(»2). 
Since  Bj(*j)  and  Bj(w2)  are  both  contained  in  B^xg)  and  no  other  block  of 
*2  is  contained  in  Bj(x2),  there  are  at  least  as  many  B^)  contained  in 
®d(*2^  as  there  are  Bj(w2)  conta*ned  in  Bd(ir^). 

Theorem  2  If  and  w2  are  PDCs  such  that  s  ir2,  then  there  exist 
partitions  and  x2  such  that  x,  c  Gfy),  x2  «  G(ir2),  and  x,  s  t2# 

Proof:  Consider  Bj(*2)  such  that  Bj lir2)  £  Bd(irj).  There  is  a  non-empty 
set  A  =  (B.Cir,)  1  B^^)  n  B^C^l  f  *>.  Let  B^x.,}  =  uA  Bf (ttj ).  Let  B^x,)  • 

B1  t*l ^  for  a11  W  «  A-  finally,  add  each  s  c  Bj(*2)  n  B<j(xt1  )  arbitrarily 
to  one  of  the  blocks  Bi(x1)  formed  from  A.  B^x,)  c  B^)  for  all  blocks  of 
tj  and  x2  formed  in  this  manner. 
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Conslder  BjU2)  such  that  B^(it2)  £  B^U-j).  For  each  such  B - (tt^) 
choose  a  different  block  B^(n^)  such  that  B^(^)  £  Bd(*2).  There  are  always 
wore  such  B^ir^J  than  Bj(ir2)  since  ir^  s  ir 2>  Let  B.(x-j)  =  (Tg)  -  B^Uj)  u 
Bj(ir2).  Obviously  B^x^)  c  R..(x2)  for  all  blocks  thus  formed. 

Some  blocks  B^fir^)  may  remain  which  have  not  yet  been  in¬ 
cluded  in  a  block  of  t-j  and  such  that  B - (tt^ )  £  B^Or,,).  Add  each  such  B. 
to  any  existing  block  of  t2  and  let  B . )  =  B.(ir^).  Thus  there  exists  a 
Bj(t2)  such  that  B.(xj)  £  B.(x2). 

Finally,  only  members  of  (ir-j )  n  Bd(ir2)  remain  to  be  assigned  to  a 
block  of  Tj  and  x2<  Add  each  s  e  Bd(*-j)  n  Bd(ir2)  to  any  block  B.(xj)  and 
to  the  block  Bj(t2)  which  contains  B.(x^).  Thus  the  resulting  block  of  x1 
Is  still  contained  in  the  block  of  x2. 

Each  block  of  xj  and  x2  contains,  by  the  method  of  construction,  only 
a  single  block  of  wj  and  w2  respectively  plus  elements  of  B(J(ir1)  and  B^tt,) 
respectively.  Thus,  x^  e  G(ir^)  and  x^  <  G(w2).  Since  for  each  block 
BjUj)  there  exists  a  Bj(x2)  such  that  B^)  £  Bj(x2),  x-,  s  x2. 

The  next  theorem  shows  that  condition  2  of  the  definition  of  it-j  u  ir2 
Is  necessary  for  the  existence  of  the  generated  partitions  for  which 
Tj  s  holds. 

Theorem  3  If  wj  and  *2  are  PDCs  such  that  for  every  i  /  d,  there 

exists  a  Bj (w2)  such  that  B^(w^)  £  Bj (w2 )  u  B^ (xr2 ) »  and  if  the  set 
<Bj(w2)|  Bj(it2)  £  Bd(ir^J>  Is  of  greater  cardinality  than  the  set 

Bjtwj)  £  Bd(ir2)},  then  there  is  no  pair  (xj,x2)  such  that 
c  G(wj),  x2  €  G ( 7t 2 ) ,  and  xj  s  x2> 


Proof:  Each  of  the  blocks  of  the  set  {B^ (trg) >  mentioned  above  must  be  com¬ 
bined  with  a  block  of  the  set  {B.j  (ir^ )}  mentioned  above  in  both  xj  and  x2  so 
that  B^(x^)  c  Bj(x2).  However,  there  are  more  such  blocks  of  *2.  Thus,  at 
least  one  block  of  x2  has  no  block  of  contained  in  it.  Since  each  block 
of  Tj  c  G(ir.j)  contains  one  block  of  ir^ ,  no  block  of  is  contained  in  that 
block  of  x2.  Thus  x^  S  x2  for  all  x^  c  G(xr^ )  and  x2  c  G(ir2). 

Theorem  4  If  ^  ^  then  *2  s  *j. 

Proof:  itj  ir2  Implies  that  for  every  (xr-j )  there  exists  a  unique 

Bj(ir2)  such  that  B- (xr1 )  c  Bj(xr2>.  Since  B^(ir2)  is  unique,  Bj(it2)  c 
u  Bd(ix1 The  sets  {B. (ir^)|  B . )  c  Bd(it2)}  and  {B^ir^l 
Bj(ir2)  £  Bd(w-| )}  are  empty.  Therefore  *2  s 


III.  FORMALIZATION  OF  TABLE  REALIZATION 


In  this  section  the  concepts  of  a  table  realization  are  formalized. 

A  "don't-care"  will  be  denoted  by  and  a  null  output  by  <J. 

Definition  5  A  sequential  machine  is  a  5-tuple  <S,I,0,6,X>,  where  S  is 
a  finite  set  of  states,  I  is  a  finite  set  of  inputs,  0  is  a  finite  set  of 
outputs,  5  is  a  function  from  S  x  I  into  S  u  {-},  and  X  is  a  function  from 
S  x  I  into  0  u  {->,  with  the  restriction  that,  for  all  s  e  S  and  i  e  I, 

«(s,1)  *  -  if  and  only  if  x(s,i)  =  -. 

The  restriction  on  5  and  x  reflects  the  informal  discussion  of  the 
previous  section  which  stated  that  transitions  and  outDuts  should  be  specified 
or  unspecified  together  and  not  independently. 

Definition  6.  A  table  realization  of  a  sequential  machine  <S,I,0,(5,x>  is  a 
triple  <J,e»T>,  where  J  is  a  set  of  index  sets,  ,  each  of  which  is  a 

finite  subset  of  integers,  for  each  i  e  I,  (  is  a  set  of  state  mapping 

functions  5.  for  each  i  e  I  from  S  onto  and  T  is  a  set  of  input  sub-table 

functions  T..  for  each  i  c  I  from  into  S  x  0,  subject  to  the  constraints 
that  1)  for  any  i,  Cj(sj)  a  ^(s^)  implies  that  either  6 (Sj,i)  =  fits^.i) 
and  x(Sj,i)  =  xfs^.l)  or  one  of  the  6's  Is  a  don't-care,  and  2)  for  all 
1  c  I  and  all  j  «  J^,  T^(j)  a  (fi(s,i),  x(s,i)\  where  s  is  such  that 
C{($)  ■  j  and  6(s,i)  is  not  a  don't-care. 

The  set  T  is  the  set  of  input  subtables,  each  entry  of  which  is  a 

next-state  and  an  output.  Thus  the  functlpn  T^  from  into  S  x  0  is  simply 

the  natural  function  from  a  table  Index  onto  the  table  entry.  The  are 
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the  sets  of  indices  used  for  each  input  subtable  and  5,  is  a  function  from 
the  state  of  the  sequential  machine  onto  the  proper  index  to  be  used  for 
that  state  under  input  i.  Figures  3  and  4  illustrate  a  table  realization 
of  Figure  2.  J,  =  J3  =  {0,1 ,2,3,},  J2  =  {0,1,2}  {0,1}  as  can  be  seen 

from  either  the  state  encoding  or  the  input  subtables.  The  Si  functions  are 
given  by  the  state  encoding  by  reading  the  proper  substring  of  the  state  for 
i.  Thus  S^l)  =  Si (3)  =  Si (4)  =  0,Si(5)  =  5,(6)  =  1,  5,(2)  =  2,  5,(7)  *  3. 

The  usual  state  table  specification  of  a  sequential  machine  is  a  table 
realization  in  which  J,  =  S  for  all  i,  the  5,  functions  are  identity  functions, 
and  each  T..  is  simply  the  i'th  column  of  the  state  table.  It  is  clear  from  the 
example  given  that  the  T.  function  is  intended  to  be  realized  by  a  table,  while 
the  5,  is  intended  to  be  realized  by  an  algorithm.  The  reading  of  a  substring 
of  the  state  variables  is  such  an  algorithm. 

Definition  7.  Each  indexing  function  5,  induces  an  input  table  partition  t, 
on  the  state  set  S  of  a  sequential  machine  such  that  Sj.s^  e  B^x,)  if  and  only 
if  ?i(Sj)  =  5,^). 


Definition  8.  For  each  input  i  of  a  sequential  machine,  6  and  X  induce  an 
'4  input  PDC  tt,  on  the  state  set  S  such  that 

— . 

1)  Sj»Sk  e  B4(w.)  if  and  only  if  fi(Sj,i)  and  6(sk,i)  are  both  speci- 

I  fied  and  efs^i)  ■  fi(sk»i)  and  A ( s ^ . i )  =  x(sk,i),  and 

2)  Sj  e  B^Wj)  if  and  only  if  «(Sj,i)  ■  -  . 


Input  table  partitions  are  a  means  of  analysis  of  table  realizations- 

. .  .  t 

of  sequential  machines  by  giving  an  algebraic  characterization  of  the 
realization.  On  the  other  hand  the  input  POC  introduce  a  synthesis  re¬ 
quirement,  as  will  be  shown  below.  That  is,  the  tr.'s  are  PDCs  to  which  a 

t 

realization's  's  will  have  to  conform.  It  is  shown  below  that  any 
table  realization  must  have  t.  s  it.. ,  while  for  a  minimal  table  entry  table 
realization  it.  ^ 

■'f  v 

Theorem  5  A  partition  -r..  is  an  input  table  partition  induced  by  of  a 
sequential  machine  <S,I,0,5,X>  if  and  only  if  s  ir^,  where  is  the  • 

input  PDC  generated  by  5  and  x  under  input  i. 

r  . 

Proof:  If  t.j  is  an  input  table  partition  then  Sj,sk  e  B4(t.j)  implies 

C|(Sj)  =  5^(sk).  This  in  turn  implies  that  either  6(Sj,iJ  *  «(sk,i)  and 
x(Sj,1)  =  X(sk,i),  in  which  case  Sy  sk  c  )  for  some  m  f  d  or 
«(Sj,1)  or  «(sk,i)  is  don't  care,  in  which  case  s^  or  sk  is  in  Bd(ir.).  Therefore 
Bm(ir . )  u  Bd(w - )  and,  since  B^tj)  =  d,  s 
If  s  then,  for  every  j,  there  exists  a  k  such  that  Bj (t^ )  c 
Bk(*1)  u  Bd(iri ).  If  st,  s^  c  Bj(tj )  then  either  1)  both  s£,  sm  c  B^) 

In  which  case  6(st,i)  *  6(sm,i)  and  x(st,i)  *  x(sm,1);  or  2)  one  or  the 
other  or  both  sA  or  sm  c  B^),  in  which  case  6(sA,1)  *  -  or  6(sm,1)  =  -  . 
Therefore  is  generated  by  a  component  of  a  table  realization. 

Theorem  6  The  number  of, table  entries  in  T  to  realize  a  sequential  machine 

Is  minimum  if  and  only  if,  for  every  1» 


Proof:  The  number  of  table  entries  in  T  is  the  sum  of  the  number  of  blocks 


of  the  t ^  partitions.  Each  and  it^  are  only  dependent  on  fi  and  X  restricted 
to  input  i,  and  are  therefore  independent  of  other  t's  and  it's.  Thus  the 
number  of  blocks  of  each  x^  may  be  minimized  independently. 

If  T|  is  an  input  table  partition  then  s  Therefore  has  at 
least  as  many  blocks  as  If  ir^  then  x^  has  exactly  the  same  number  of 
blocks  as  which  is  the  minimum  possible.  Also,  ir.  implies  x^  s 

and  x.|  results  in  a  minimum  entry  table. 

If  xj  s  and  x ^  has  a  minimum  number  of  blocks,  then  the  number  of 
blocks  of  x.j  and  w.j  are  the  same.  Also,  for  each  there  exists  a  Bk(i^) 

such  that  Bj(x.j)  £  B^U^)  u  Bd(ir,|).  Since  the  number  of  blocks  are  the  same, 
the  j-k  correspondence  is  unique.  Therefore  for  every  there  exists  a 

Bj(xj)  such  that  B^U^)  £  Bj(x^)  and  each  Bj(x^)  contains  exactly  one  block  of 
.  Thus  w j  ss  • 


Theorems  5  and  6  show  that  in  order  to  find  a  partition  x^  to  give  a 
minimum  size  table  T,  any  member  of  G(tr^ )  may  be  chosen  for  each  input  PDC 

Definition  9.  An  encoding 'E(o)  of  a  partition  p  on  S  is  a  binary  matrix  of 
dimensions  #(S)  *  e,  such  that  s^  and  Sj  are  members  of 
Bk(p)  if  and  only  if  row  i  and  row  j  of  E(p)  are  identical. 

The  encoding  E(S)  is  a  particular  case  of  E(p)  where  p  Is  the  trivial 
zero  partition  of  S  (each  s  e  S  is  in  its  own  block). 

Definition  IQ  An  encoding  of  a  string  of  partitions  ECp^..^)*  is  formed 
from  the  encodings  E (p |T  of  the  individual  partitions  os  follows. 

D  E(Plp2...pk)  -  E(p,)  If  k  -  1  — — 

2)  E(Pjp2...pk)  8  E(pjp2...pk_j)  augmented  by  E(p^). 
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- - ~~By -convention,  a  string  will  be  informally  referred  to  as  an 

encoding,  while  what  is  meant  is  E(pjp2...p|(). 

A  minimum  table  entry  realization  may  be  easily  constructed  for  any 
sequential  machine.  Arbitrarily  choose  a  t.  e  G(ir^)  for  each  i  e  I.  Choose  a 
minimum  bit  E(-r.j).  The  number  of  bits  needed  for  each  row  of  E(t^)  is 
riog2(#(Tri))l.  Let  E(S)  =  The  substnn9  contributed  by 

each  t.  is  used  to  index  each  input  subtable  T,.. 

Figure  7  shows  such  an  encoding  applied  to  the  machine  of  Figure  2.  * 

The  machine  which  was  encoded  in  four  bits  in  Figure  3  has  been  encoded 
in  seven  bits  in  Figure  7  because  no  sharing  of  bits  was  used.  Finally, 

Figure  8  lists  the  input  table  partitions  for  Figure  3. 

Since  each  n.  of  Figure  7  is  less  specified  than  the  corresponding 
of  Figure  8,  the  table  realization  of  Figure  3  Is  a  minimum  entry  table 
realization.  The  primary  means  of  reducing  the  number  of  bits  in  the 
encoding,  and  consequently  in  each  entry  of  the  table,  is  to  share  the  bits 
of  the  encoding  among  several  inputs.  It  may  also  be  noted  that  the  's 
of  Figure  3  are  very  different  from  those  of  Figure  7.  It  is  the  judicious 

choice  of  the  t^’s  that  allows  the  sharing  of  bits.  The  following  sections 
describe  methods  of  choosing  t^'s  to  give  maximum  or  near  maximum  sharing  of  bits. 

B|y  using  the  concepts  developed  thus  far,  several  bounds  on  the  result¬ 
ing  table  realization  may  be  easily  calculated: 


Table  size 


Size  of  E(S)  with 
min.  table  size 


Maximum 

Minimum 


IV.  SHARING  OF  CODE  BITS  BETWEEN  INPUT  PDCS 


So  far,  sharing  of  code  bits  has  been  mentioned,  but  only  informally. 
Sharing  of  code  bits  between  input  PDCs  must  be  done  at  a  finer  level 
than  input  partitions,  and  so  a  suitable  algebraic  structure  is  needed. 

In  order  to  analyze  and  synthesize  the  sharing  of  partitions  in  the  en¬ 
coding  of  two  or  more  t's,  operations  on  partitions  must  be  defined. 

It  Is  assumed  that  conventional  partition  operations  and  properties  are  • 
understood  by  the  reader  [6l. 


Definition  11.  An  encoding  of  a  string  of  partitions  Efp-jpg.  •  .p^)  is 
said  to  be  a  minimum  table-size  subset  encoding  of  a  sequential  machine  if 
and  only  if  for  each  input  PDC  it..  there  exists  a  subset  R^  of  (p^,...,pk} 
called  a  row  set  such  that  ir-s,  n  p.. 

5  ’rRi 

Definition  12.  A  subset  encoding  inPut  PDCs  through  ifn, 

where  n  is  the  number  of  inputs,  defines  k  sets  of  PDCs,  called  column 
sets  (C-.lsjsk)  such  that  C.  *  {*.»  !p -eR.-}. 

"  '  J  J  *  w  ■ 


A  row  set  is  simply  the  set  of  ps  used  to  encode  a  specific  ir^,  and 
column  set  is  simply  the  us  in  whose  encoding  p^  is  used. 

In  the  example  of  Figure  3,  p^  through  p^  are  each  induced  on  the  state 
set  by  each  of  the  bits  of  the  encoding  y^  through  y^  respectively. 

Pj  •  (1, 2,4,6, 7) (3,5) 
t>2  -  (1.3,4,S,6)(2,7) 

P3  -  (1.2. 3,4) (5,6,7) 
p.  -  (1,2,3, 5) (4,6,7) 


Definition  13.  A  minimum  bit,  minimum  table-size  subset  encoding  of  a 
sequential  machine  is  a  minimum  table-size  substring  encoding  such  that 

1)  I  f log2  is  less  than  or  equal  to  the  same  summation  for  all 

i 

other  minimum  table-size  substring  encodings  of  the  same  machine,  and 

2)  for  all  riog  )i  .  J  flog2  #(p.)l  . 

p.eR.  J 

1  i 


Lemma  lf6l.  If  p  =  Pj'P2  then  P  5  Pj»  P  s  P2» 

Any  subset  of  an  encoding  may  be  used  for  an  I..  For  example,  in  p.p7p_p 

X  1  2  3 

if  Pj*P2  =  tj  then  pjP2  may  be  used  for  Ij.  A  possible  use  of  PjPjPjp^ 
may  be  shown  diagramatically  as: 

P1  p2  P3  p4 

Tj  0  1  10 

t2  1  1  0  0 

t3  0  0  1  1 

t4  1  0  0  0 

- -ST  - 

The  concatenated  partitions  of  the  encoding  are  listed  across  the  top,  the 
input  table  partitions  on  the  side^-xnd  the  subset  corresponding  to  each 
input  table  partition  has  sT  T  under  each'p  used  for  it.  This  diagram  is 


-20- 


Lemma  2  [6] .  The  sum  of  two  partitions  pj  +  p2  is  the  least  upper  bound 
of  Pj  and  p 2 • 

Theorem  7.  If  a  partition  p  can  be  shared  by  input  partitions  x^  and  x 
then  x^  ♦  x^  s  p. 

Proof;  Since  the  sharing  of  p  implies  there  exists  x/  and  x/  such  that 

x.  *  x'  *p  and  x.  *  x' *p,  it  follows  that  x.  s  p  and  x.  £  p.  Since 
i  i  3  J  1  J 

x.  ♦  x^  is  the  least  tipper  bound  of  xi  and  Tj»  Ti  +  Tj  s  p* 


Theorem  8.  Consider  a  minimum  table-size  subset  encoding  E(PjP2* • *0^) • 

Let  x.  *  n  P.  for  every  i  in  the  set  of  inputs.  For  each 

1  y  Ri  3 

component  partition  p^  of  the  encoding. 

In  5  'j 

vs 

Proof:  Since  p.  appears  as  part  of  the  encoding  of  all  x^  where  i^eC^, 

xisp^  for  all  xeCj.  Since  the  sura  of  partitions  is  the  least  upper  bound 

of  the  partitions,  and  p.  is  an  upper  bound. on  all  the  x.  for  *  eC. ,  £  x.£p.. 

J  1  J  *  *C  1  J 

1  j 

The  theorems  of  this  section  thus  far  have  primarily  dealt  with  partitions 
induced  by  an  encoding,  and  the  properties  of  these  partitions.  They  give 
little  help  in  finding  such  an  encoding  from  the  input  PDCs.  Operations  that 
lead  toward  such  an  encoding  are  considered  next. 

In  order  to  discover  the  ways  in  which  two  PDCs,  "j  and  ir^,  may  share  a 
partition  p  in  an  encoding,  enumeration  of  every  p  greater  than  or  equal  to 
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the  sums  x^+x^  for  all  (x^.x^)  in  G(Hj)  XG(ir2)  may  be  performed.  How¬ 
ever,  a  "closed  form"  of  this  set  of  partitions,  just  as  a  PDC  is  a 
"closed  form"  of  the  set  G(ir.),  is  of  greater  value.  It  is  this  set  of 
partitions  that  is  considered  the  sum  of  two  PDCs.  This  sum  must  pre¬ 
serve  the  characteristics  which  are  considered  essential  in  the  encoding 
desired.  Specifically,  minimum  table  size  is  to  be  preserved.  The  major 

problem  is  that  each  of  the  two  PDCs  to  be  added  have,  in  general,  different 

• 

distinguished  blocks.  Because  of  this  fact,  every  block  of  must  contain 

at  least  one  block  of  and  one  block  of  irg.  This  requirement  arises  from 
the  objective  of  minimum  table  size.  If,  by  taking  the  sum  of  two  PDCs,  a 
block  is  introduced  in  which  no  block  of  one  PDC  is  contained,  then  no  matter 
what  partition  the  sum  is  combined  with  by  the  product  operation,  that  block 
will  stay  distinct,  since  the  product  operation  tends  to  split  blocks,  not 
join  them.  Therefore,  in  the  final  encoding  there  will  be  a  block  which  is 
entirely  don't-care  for  that  input,  and  a  table  entry  will  be  wasted.  Stated 
more  formally,  ir  x  since  one  block  of  x  has  no  block  of  n  contained  in  it. 

The  definition  of  the  sum  of  two  PDCs  is  a  simple  extension  of  the  sum  of 
two  partitions. 

Definition  j4.  The  sum  of  two  PDCs,  V  *  ttj  +  on  a  set  S  is  a  PDC  such  that 
1)  s.|  and  Sj  are  in  the  same  non-distinguished  block  of  *  if  and  only  if  there 
exists  a  sequence  in  S,  s^  ■  SQ,Sj,...,sn  *  Sj  for  which,  for  0  s  1  s  n-1,  st 
and  s1+j  are  in  the  same  non-distinguished  block  of  either  or  and  2)  s^ 
and  Sj  are  in  the  distinguished  block  of  if  and  only  if  they  are  in  the  dis¬ 
tinguished  blocks  of  both  and  ir^* 
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Example:  V  =  (1 ,2)(3)(4)(5)(6)<7,8,9> 

*2  *  (1 )(2)(3,4)(7)<5,6,8,9> 

*  -  (1»2)(3,4)(5)(6)(7)<8,9> 

This  definition  of  the  sum  brings  together  in  one  block  any  states  that 

are  in  the  same  blocks  of  either  or  t^,  but  it  does  not  achieve  the  other 

requirement  for  preserving  minimum  table  size,  since  every  block  of  v  does  not 

contain  a  block  of  both  and  In  the  example,  (7)  contains  no  block  of 

ifj,  and  both  (5)  and  (6)  contain  no  block  of  i^.  By  the  method  of  computing  o 

the  s  relation  will  never  hold  between  ^  and  if  it  has  blocks  contained  in 

B  (ir_ ) .  The  s  relation  between  PDCs  holds  if  and  only  if  there  exists  a  pair 
d  1 

of  partitions  in  the  sets  generated  by  the  PDCs  between  which  the  s  relation 
holds.  In  order  to  share  code  bits  between  two  inputs,  the  <  relation  must  hold 
between  the  ts  used  for  those  inputs  and  p.  Thus  it  is  essential  that  if  a  sum 
is  to  be  used  in  finding  sharing  qpportunities,  then  the  s  relation  must  be  made 
to  hold.  In  order  to  achieve  this  the  concepts  of  quotients  and  block  size  sets 
are  now  introduced. 

Definition  15.  The  relation  weakly  less  than  or  equal  holds  between  two  PDCs 
*<1  and  ff2(ffi  -ft-?)  and  onJy  for  every  ^  d»  there  exists  a  B j ( tt2 ) - 

such  that  BjU-j)  £  u 

The  weakly  less  than  or  equal  relation  does  not  require  any  relationship 
between  the  blocks  entirely  contained  in  the  other  PDCs  distinguished  block. 

As  Theorem  3  has  proven,  this  relation  does  not  guarantee  the  existence  of 
generated  partitions  between  which  the  less  than  or  equal  relation  holds. 


T 


Theorem  9.  If  and  -n^  are  PDCs  on  S  and  ♦  =  "-j  +  *2  then  *1  ^  and  *2 

Definition  18.  If  if  and  ^  are  POCs  on  S  and  v  <u  ♦  then  ♦  defines  a  quotient  PDC 
♦/ir  on  the  blocks  of  u  and  the  members  of  the  distinguished  block  of  jl  such  that 
if  a  and  8  are  either  B.(n)  or  f | S|  e  Bd(ir)}  then  o  and  8  are  in  the  same 
block  of  if  and  only  if  a  and  8  are  contained  in  the  same  block  of  ♦. 

Example:  *3  =  (1,2,3)(4,5)(6)(7)(8)<9,10,11> 

=  (1 )(3)(4,6)(9)<2,5,7,8,10,11> 

♦  =  (1 ,2,3)(4,5,6)(7)(8)(9)<10,11> 

♦/if  3  »  ((1 ,2,3))((4,5)(6))((7))((8))(<9>)<10,11> 

♦/if  4  =  ((1  )(3)<2>)((4,6)<5>)(<7>)(<8>)((9))<10,11> 


The  notation  used  simply  breaks  up  each  block  of  ♦  into  its  component 
blocks  and  don't-care  states  of  *3  or  Thus,  the  block  ((1)(3)<2>)  of 
♦/n^  shows  that  the  non-distinguished  blocks  (1)  and; (3)  plus  the  member  <2> 
of  the  distinguished  block  of  w ^  are  contained  in  block  (1,2,3)  of  ♦. 

Definition  19.  If  *  and  ♦  are  PDCs  such  that  v  </  then  the  block  size  set  of 
the  quotient  PDC.  BSS  (♦/*),  is  an  array  of  integers  ai  such  that  a<  is  the 
number  of  non-distinguished  blocks  in  B,j  (♦/*). 

Example:  (continued) 

BSSf^/uj)  =  1,2, 1,1,0 
BSS^/^)  =  2,1 ,0,0,1 


Theorem  10,  If  $  =  +  n2,  p  <;  and  Bd{^ * )  c  Bd(*),  then  it|  s  if  and 

only  if  BSS(^' /tt-j )  includes  no  zeros.  (Similarly  for  tt2). 

Proof:  There  are  no  non-distinguished  blocks  of  ir^  contained  in  Bd(if,)  by  the 
method  of  construction  of  < P.  Since  B^OJ*')  c  Bd(if>)  there  are  no  non-distinguished 
blocks  of  contained  in  Bd(if*‘). 

If  ifj  £  '■p'  then,  by  the  definition  of  <,  since  no  non-distinguished 

blocks  of  itj  are  contained  in  BdCf<'},  no  non-distinguished  blocks  of  if,'  are 

contained  in  Bd(n^).  Therefore,  for  each  B.fy1')  there  is  at  least  one  B^tt^) 

such  that  £  B j (if; ' )  u  (4» ' ) .  By  the  method  of  constructing  0  and  the 

fact  that  <f;  s  if;'  it  follows  that  B.(ir  )  c  B.ty' )  and  thus  the  ith  element  of 

0 

BSS(if.7iT1)  is  at  least  1.  Thus  no  element  of  BSS^'/ir-j)  is  zero. 

If  BSSfifi'Aj)  contains  no  zeros,  no  non-distinguished  block  of  i|»*  is 
contained  in  The  construction  of  'P  -  +  ir2  assures  that  for  each 

B^(^)  there  exists  a.  j  such  that  B^wj)  c  Bj('J').  Since  ♦  £  <]>•  and 

5.Bd(^)  there  exists  a  Bj(i|>‘)  such  that  B.-fnj)  £Bj(rj,*)*  Therefore, 

Theorem  10  provides  a  method  of  constructing  PDCs  {iW  from  a  sum  of  two 
PDCs  W|  and  *2  such  that  w]  and  ir2  are  less  than  or  equal  to  the  PDCs,  allowing 
the  potential  sharing  of  partitions  generated  from  {'{»•}.'  between  partitions 
generated  from  and  ir2«  Since  7  +  *2  ^  *  and  ®d^'  ^ 

we  must  construct  by  joining  blocks  of  i>  to  form  blocks  of  if»'  such 

that  no  block  of  has  a  zero  in  the  block  size  set  of  the  quotient  of 

either  w  or  This  joining  can  be  done  by  considering  only  the  block 
size  sets  of  and  1^,  treating  their  elements  as  pairs,  and  adding  together 
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elements  of  the  block  size  sets  in  order  to  eliminate  zeros  from  the  resulting 
block  size  sets.  For  example,  it  can  be  seen  from  BSS(^/n3)  and  BSS( 
that  if  the  fourth  and  fifth  elements  are  joined  and  the  first  and  third 
elements  are  joined,  the  resulting  BSSs  have  no  zeros.  Thus  BSS(<|>7it3)  *  2,2,1 
and  BSS((|»'/it^)  =  2,1,1.  By  joining  the  corresponding  blocks  of  ^ ,  the  result 
i|»’  =  (1 ,2,3,7)  (4,5,6)  (8,9)  <10,11>  is  realized.  Figure  9 


summarizes  all  of  the  upper  bounds  on  such  i p'  for  it  and  *  .  Every  other 

3  4 

with  similar  properties  can  be  shown  to  be  greater  than  one  of  those 


listed,  while  the  less  than  or  equal  relation  does  not  hold  between  any 
pairs  of  <f> 1  given. 


By  means  of  sums  of  pairs  of  input  PDCs.'all  those  PDCs  which  can 
be  shared  by  each  pair  can  be  found.  An  additional  constraint  must  be 
applied  to  these  POCs  to  guarantee  that  the  second  condition  of  minimum 
bit,  minimum  table  size  definition  is  not  impossible  to  satisfy.  This 
condition  is  that  the  number  of  bits  needed  to  encode  the  substring 
used  for  each  input  must  be  equal  to  the  smallest  number  of  bits  required 
to  encode  that  input  partition.  Consider  the  *3,  *4  example  as  an  appli¬ 
cation  of  this  constraint.  Since  *3  has  5  blocks  it  needs  three  bits  to 
encode. 

Similarly  ^  needs  2  bits.  The  number  of  bits  needed  in  the  shared 
encoding  is  the  log  of  the  number  of  non-distinguished  blocks  in  the 
shared  PDC  plus  the  log  of  the  maximum  block  size  set  element  in  the 
quotient.  Figure  10  summarizes  these  statistics  for  the  it's  found  for 
*3  and  V 
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Note  that  the  fact  that  one  of  the  lower  bounds  doesn't  satisfy 
condition  2  does  not  preclude  a  larger  PDC  from  satisfying  it.  The  BSS 
provides  enough  information  for  deciding.  For  exampl-e,  the  first  i|»', 

(1,2,3)  (4,5,6)  (7,3,9)<10,11>  does  not  satisfy  condition  2. 

The  BSSs  are  1,2,2  and  2,1,1.  The  number  of  bits  used  for  *3  and  ^ 
by  this  PDC  are  3  and  3  respectively.  must  use  only  2.  The  quotients 
each  use  1  bit.  Producing  a  larger  PDC  can  only  join  blocks.  Thus  the 
quotients  remain  the  same  or  larger.  However,  if  the  number  of  blocks  in  <|/  is 

reduced  to  2,  the  number  of  bits  in  the  quotient  may  become  2  for  ir3 
and  remain  1  for  ir^.  Thus  the  problem  becomes  one  of  combining  elements 
of  the  BSSs  in  such  a  way  that  the  BSS(^/ir3)  elements  do  not  go  above  4 
and  the  BSS^/ir^)  do  not  go  above  2.  There  is  only  one  way  in  which 
this  can  be  done,  by  combing  the  second  and  third  blocks,  giving 
*'•  (1,2,3)  (4, 5, 6, 7,8, 9)  <10,11>  ,  and  BSS(*7w3)  =  1,4,  BSS(*7*4)  =  2,2. 

The  fol Irving  definition  formalizes  the  constraints  on  PDCs  shared 
between  two  or  more  input  PDCs.  The  extension  from  two  to  more  than  two 
is  a  simple  generalization.  PDCs  which  are  themselves  sums  of  input  PDCs 
may  be  added  to  give  PDCs  which  may  be  shared  between  all  components  of  the 
sum,  provided  a  suitable  encoding  string  can  be  found. 

n 

Definition  1ft.  Let  <p  ~  Then  ip  is  compatible  with  it.  for  1  s  i  <  n 

i*l  - . - ! - 

if  and  only  if  there  exists  a  ip'  such  that,  ij>  s  \p't  Bd(ip')  £  Brf(^),  and,  for 

all  1  ,  ^"loggUU'  )?  +  ^loggOnaxfBSSU'/ir. )?  3  ^logg#^- 1  and  no  element 

of  BSS^'/ni )  =  0.  Any  such  ip '  is  said  to  be  completely  compatible. 

The  definition  of  compatibility  leads,  in  the  general  case,  to  art 
enumerative  search  for  a  with  the  properties  listed.  This  search,  while 


.1.1  a. 


- 


li  irnmA^mi  ■  1  m  In  il 


. .  T 

i  m  hm  l,m  km  Uftiliah 


-27- 


difficult  in  general,  may  be  eliminated  if  the  existence  or  impossibility 
of  such  a  may  be  established  by  the  application  of  several  theorems. 

Consider  ^  =  *■)  +  *2  an<1  ^et  S12  be  bbe  set  ^ocl<s  ^ 
both  non-zero  BSS  elements,  S-j  the  set  of  blocks  with  zero  elements  in 
BSS  U/ir2)»  and  S2  those  zero  elements  in  BSS  U/u-j).  The  largest 
number  of  blocks  a  <*>'  which  satisfies  compatibility  may  have  is  #(S^)  + 

min(#(S-|  ),# (S2 ) )  since  no  elements  of  the  BSSs  may  be  zero.  It  is  an  easy  - 

task  to  find  if  a  ip*  with  that  many  blocks  exists.  Let  c  =  riog2( (^(S-jg)  + 

9 

min (# (S^ ) ,  #(S2)))1  be  the  number  of  bits  used  in  common  between  and  ir2  with 

such  a  1 1>' .  Then  r1  =  rioggC^f^i  ))l~c  is  the  number  of  bits  which  remain  to 

encode  tt, ,  while  r2  =  riog2(#(iT2) )]-c  is  the  number  of  bits  which  remain  to 

encode  t^.  Assume  without  loss  of  generality  that  #(S.j )<#(S2).  Then  the  blocks 

of  ^  with  non-zero  elements  in  BSS 4/it-j )  are  not  combined  at  all,  and  blocks  of 

S-|  are  each  combined  with  a  block  of  S2-  Only  blocks  of  S2  in  excess  of  #(S^) 

remain  to  be  combined  with  other  blocks.  These  blocks  all  have  elements  in 

BSS(^/tr-| )  of  zero,  and  therefore  do  not  effect  compatibility  with  ir-j.  In 
addition,  they  have  elements  of  1  in  BSS{ >  and  therefore  are  arbitrarily 

distributable  in  any  blocks  of  with  room  for  more  ir2  blocks.  The  amount 

of  room  in  each  block  is  simply  2r2  -  the  ith  element  of  BSS(tp/ir2).  If  the 

total  amount  of  room  over  all  the  blocks  of  S^2  and  S-j  for  blocks  of  ir2  is 

larger  than  the  number  of  excess  blocks  of  S2,  then  i|»  is  compatible  with  and 

*2* 

Theorem  u.  Let  4>  *  7^  +  *2.  Assume  #(S-|)  s  #(S2).  <l>  is  compatible  with  ir-j 

and  w2  if  every  element  of  BSS(>p/ir^ )  s  2rl ,  every  element  of  BSS(^/ir2)  s  2r2, 
and  (#(S12)  +  HS}))  •  2r2  2  J  BSS(*/*2). 

Proof:  From  above  discussion. 
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Theorem  12.  Let 


exists  an  1  such  that 


n 

*  =  7  w..  Is  not  compatible  with  Is  1  s  n  If  there 

•j=1  i  1 

hat*  log2(#(wi)p  =  ITog2(rnax(BSS(<|;/Tr..))P  . 


Proof:  If  the  number  of  bits  available  for  is  equal  to  the  number 
of  remaining  bits  other  than  the  common  bits  to  encode  *.  then  there 
must  not  be  any  common  bits.  Hence  it.  is  not  compatible  with  tp. 


Other  theorems  may  be  developed  to  improve  the  search  for  a  com¬ 
patible  <(»'.  However,  these  are  only  necessary  for  automating  these 
techniques  in  a  computer  based  optimization  program.  These  will  be 
described  in  a  subsequent  paper.  Examples  to  be  described  in  this 
paper  may  be  easily  done  by  hand  without  large  searches. 

Ir.  the  discussion  of  analysis  techniques  it  was  seen  that  a  p.  of 

J 

a  subset  encoding  is  greater  than  or  equal  to  the  sum  of  x.s  for 
which  it  is  used,  while  each  x  is  the  product  of  the  p.s  encoding  it. 

*  J 

The  sum  has  been  generalized  to  a  sum  of  PDCs  such  that  a  PDC  <|»j  may  be  part 
of  an  encoding  if  and  only  if  it  bears  a  specified  relationship  to  the 
sum  of  the  ir..s  for  which  it  is  used.  A  similar  generalization  of  product 
is  needed  to  judge  whether  a  subset  of  i|>.s  may  be  used  to  encode  a  specific 

J 

The  following  product  operation  is  defined  to  provide  a  necessary  con¬ 
dition  for  the  set  of  ^ .s  to  ultimately  yield  p.s  whose  product  x.  is  in 

J  J  * 

The  distinguished  blocks  of  the  <|»s  plus  possible  combining  of  blocks 
may  subsequently  destroy  this  possibility. 

Definition  ig.  The  product  of  two  PDCs  is  the  PDC  such  that 

1)  Sj  and  Sj  are  in  the  same  non-distinguished  block  of  ip  if  they  are  in 
the  same  non-distinguished  block  of  both  ^  and  an^  2)  s^  is  in 
if  Sj  is  in  B^Uj)  or  s^  is  in  B(J(I|»2). 


Theorem  13.  In  a  partially  specified  subset  encoding  ^ 

input  PDCs  ir-j  through  irn>,such  that  each  ^  is  completely  compatible 

with  all  it •  c  C.,a  necessary  but  not  sufficient  condition  for  the  existence  of 

■  J 

a  minimum  table  size  subset  encoding  pip2*“p|c»  such  that 

e  G( ^ )  for  all  i,  with  identical  row  and  column  sets  R  and  C» 
is  that  for  all  ffj. 


’1  S^JcR,  ♦j1' 

Proof:  None  of  the  non-distinguished  blocks  of  ir.  are  contained  in 
the  distinguished  block  of  This  arises  from  the  fact  that  Bd 
of  each  ^  is  contained  in  of  the  sum  of  all  in  Cj,  which  is 

the  intersection  of  the  B^^Js.  Therefore  no  non-distinguished 
block  is  contained  in  any  for  ^jeR. . 

The  requirement  for  a  minimum  table  size  subset  encoding  is 


that  it.  s  (  nR  p.)  for  all 
1  s  pjeKi  J 

appear  in  the  blocks  of  ,n  D  \J>. 

*jcRi  3 

in  the  various  ip.s  cannot  cause 

J 


i.  Since  all'  the  blocks  of  w.  already 
the  assignment  of  states  in  Bd(w^) 
the  blocks  of  to  either  be  split  apart 


or  joined  together  in  the  product.  Thus  w.  s.  (  n  p  ij>  )  is  a  necessary 

1  3  Vj*  ^ 

condition  for  w.  <  (  nD  p.)  if  P*  e  G(ip.). 

1  5  j  J  J 

This  condition  is  not  a  sufficient  condition  because  some  don't-care 


states  of  the  ip . s  may  be  already  assigned  in  such  a  way  as  to  cause  them 

v 

to  form  a  block  or  blocks  of  their  own  in  the  final  product  of  PjS, 
while  they  are  in  the  don't-care  block  of  the  product  of 


The  following  example  illustrates-the-insufficiency  of  Theorem  13. 


Let  ir,  =  (1  )(2)(3)(4)(5)  <6,7>, 


(1,3,5)(2,4,6,7), 


0  »2,5)  (3,4)<6,7>) 


'  T0.2, 3,7)3575)  (4)7 

*j)  =  0)  (2)  <3)  (4)  (5)  <6,7>  = 

However,  note  that  the  product  of  the  first  two  ip -s  *  (1 .3) (2 ,7) (4) (6) - 

J 

No  matter  where  the  6  is  assigned  in  the  third  ip - •  it  will  not  bring  6  into 

J 

a  block  with  another  block  of  it..  Therefore  no  (  n  D  p.)  exists  in  which 

•  PjCKj  j 

pj 

Note  that  the  7  is  not  a  problem,  since  it  may  be  assigned  with  the 
(1,2,5)  block  of  the  third  and  still  remain  within  the  block  (2,7)  of 

J 

the  product,  which  contains  the  (2)  block  of  ir... 

V.  PAIRWISE  COMPATIBILITY  AND  POSSIBLE  PROFILES 

Compatibility  concepts  are  now  used  to  form  a  strategy  for  finding 
an  optimal  encoding.  In  the  process  of  determining  compatibility,  a  search 
is  made  for  the  largest  c  such  that  the  number  of  blocks,  2C,  may  contain 
the  elements  of  the  BSSs  without  violating  any  of  the  constraints.  If 
c  >  1,  the  PDCs  considered  are  compatible.  If  this  is  done  for  all  pairs 
of  Input  PDCs,  then  the  maximum  pairwise  overlap  of  input  PDCs  is  found. 

In  addition,  new  upper  and  lower  bounds  on  the  total  number  of  bits  may 
be  obtained. 

Theorem  14.  Let  c^  be  the  maximum  bit  sharing  between  input  PDCs  w.  and  ir^. 
Hie  largest  *  Hogg^^i ))3  +  nog^#^))!  -  c.j  over  all  i  and  j  where 
1  f  j  is  a  lower  bound  on  the  number  of  bits  in  the  encoding.  The  smallest 
I  tjj  +  I  #(1^)  such  that  every  input  appears  at  least  once  as  an  i,j,  or  k 
Is  an  upper  bound  on  the  number  of  bits  in  the  encoding. 

Proof;  tjj  is  simply  the  total  number  of  bits  required  to  encode  * i  and  *  . 
if  they  are  allowed  to  overlap  to  the  largest  degree  possible.  No  encoding 
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may  be  smaller  than  the  required  number  of- bits  necessary  to  encode  any  two 

/ 

of  the  input  PDCs. 

An  upper  bound  is  found  by  assuming  that  no  further  sharing  of  bits 
than  pairwise  can  take  place.  Then  we  may  choose  pairs  (and  any  remaining 
single  input  PDC)  to  cover  all  the  input  PDCs  with  the  least  total  number 
of  bits. 

The  strategy  for  choosing  an  encoding  will  be  illustrated  with  the 
example  state  table  given  in  Figure  2,  with  input  PDCs  given  in  Figure  7. 

The  following  PDCs  are  the  pairwise  sums  of  the  input  PDCs  of  Figure  7  . 

and  their  compatibility  status.  Details  are  shown  in  some  cases  only. 


*1,2  =  V’2  =  <1.3K2.7)<4)C5)(6) 

•  <0.3))  «2)(7))(<4>)  (<5>)«6>) 
*1>2/"2  •  (<1»3>)((2,7))((4))((5)){<5>) 


compatible 


BSS(*1 .2/wl)  =  1»2»°t0»l 

BSS^l,2/lr2^  * 


’  r^  =  1,C|  7  -■  1,  r^*2  *.  1  t  '  BSS  becomes  2,2 

1  l.Z  2  1>2 


*1,3  VV  0.3)(2)(4)(5)(6.7) 


compatible:  r1 ,3  *  1 ,c,  -  -  1 ,  r1*3  =  1  ,  BSS  becomes  2,2 

1  1,3  3  2,2 


*1.4  *  Vw4  *  0 .2,3,4) (6)(7)<5> 
*2.3  "  Vw3  *  (1  »3)(2,6,7)(4)(5) 


incompatible:  Theorem  12. 


compatible:  rj»3  -  1,  Co  ,  *  1  ,~r?73'  l  "  "BSTbecomes  1 ,2 

—  C ,  J  3  *  »  An 


2.2 


*2.4  *  V* 4  =  0*2,4, 7)(3)(5)<g>  ' 

compatible:  r^*  *  1. 02^4*1,  =  0,  Theorem  11.  BSS  becomes  2,1 

1»1 

i 

♦3  4  *  *3+1T4  *  (1 ,2,3,4)(5)(6,7)  Incompatible:  Theorem  12. 

The  largest  t. .  of  these  is  t,  ,  a  3.  Therefore,  the  smallest 
possible  encoding  is  three  bits.  Since  tj  j+tg  4=5,  five  bits  is  an 
upper  bound.  The  search  for  the  optimal  encoding  begins  with  the  ij/.  . 
of  the  lower  bound,  and  overlaps  the  other  PDCs  on  this  in  all  possible 
ways,  subject  to  the  maximum  overlaps  computed  in  the  above  sums.  Only 
when  no  encodings  of  the  smallest  size  are  shown  to  be  possible  are  encodings 
of  larger  sizes  considered.  A  possible  profile  is  a  binary  matrix  with 
one  column  for  each  bit  in  the  encoding  and  one  row  for  each  PDC  included 
In  the  encoding.  Ones  in  the  matrix  indicate  which  bits  are  assigned  to 
the  PDC.  The  input  PDCs  are  first  ordered  in  descending  rlog2(#U- ))n  order 
in  order  to  insert  the  more  difficult  PDCs  first.  The  first  two  PDCs  are 
those  giving  the  lower  bound.  The  resulting  order  for  this  example  is 

*1  •w2*ir3*ir4* 

The  subset  encoding  to  be  illustrated  is  further  constrained  to  be  a 
substring  encoding,  which  is  a  subset  encoding  in  which  each  subset  is 
contiguous.  This  constraint  is  used  in  order  to  produce  encodings  that 
can  be  easily  implemented  by  a  single  shift  operation  followed  by  a  single 
AND  operation  on  many  conventional  computers,  whether  large,  mini,  or  micro. 
It  is  not  easy,  in  general,  to  assemble  an  arbitrary  subset  into  a  table 
Index.  All  methods  illustrated  hold  for  a  subset  encoding  as  well,  there- 
fbre  the  illustration  does  not  lose  generality. 


The  first  partial  possible  profile  is  shown  in  Figure  11,  and 
labeled  ppl.  PDCs  are  assinged  from  left  to  right,  may  be  assigned 
anywhere  in  the  three  bits.  *2  must  then  satisfy  the  overlap  constraints.  Thus 

the  leftmost  position  in  which  it  can  be  assigned  starts  at  bit  2, 
since  it  can  only  overlap  in  one  bit.  (c^  2  *  !)• 

When  ttj  is  added  to  the  profile,  it  is  found  that  it  must  either 
overlap  or  *2  in  two  bits,  which  is  impossible  since  both  Cj  ^  and 

c2,3are1- 

Since  cannot  be  added  to  the  partial  profile,  we  must  backtrack, 
to  see  if  we  can  modify  ir^  and  ir2  to  allow  insertion  of  *3  in  three 
bits.  Since  u2  cannot  move  to  the  right  and  moving  to  the  right 
will  only  produce  mirror  images  of  previous  profiles,  ir3  cannot  be  added  in 
three  bits. 

Four  bit  profiles  are  generated  next.  We  obtain  pp2  and  pp3  by  insert¬ 
ing  ttj,  ir2,  and  n3  at  their  leftmost  positions.  Since  ir^  is  incompatible 
with  tt i  and  tt3,  and  or  tt3  are  in  every  position,  cannot  be  inserted 
into  this  partial  profile.  We  therefore  backtrack  to  pp2,  move  *2  to  the 
right,  and  insert  ir3  in  its  leftmost  position.  We  are  then  able  to  insert 
in  the  last  bit,  for  pp6. 

This  profile  includes  all  PDCs  and  satisfies  the  overlap  conditions 
generated  above.  The  overlap  conditions  tell  us  that  if  the  two  PDCs 
overlap,  there  exist  partitions  such  that  a  minimum  entry  encoding  can 
be  achieved.  However,  we  have  no  guarantee  that  the  partitions  used 
for  the  *3  overlap  above  are  also  useful  for  the  ir2,  ir3  overlap, 
for  example. - — — .  — - — 

At  this  stage  we  oust  then  test  this  "possible  profile"  to  see. If 
in  fact  we  can^Ind^foiiitlllBBl  entry  encoding  (by  our  method  of 
finding  It,  it  is  already  minimum  bitY^ _ 
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VI.  EVALUATION  OF  POSSIBLE  PROFILES 

Each  bit  of  the  possible  profile  of  an  encoding  must  satisfy  several 
constraints  in  order  that  it  will  eventually  yield  a  partition  in  a 
minimum  bit,  minimum  entry  encoding.  What  is  tested  is  whether  the 
several  constraints  can  be  met  simultaneously.  Let  us  label  the 
columns  of  the  encodings  as  ^3*  and 

Each  if/,  must  satisfy  the  constraint  that  it  is  completely  compatible 

J 

with  all  ir.  in  C..  In  addition,  the  constraints  s  (  n  i|>.)  must  hold 
>0  is  *  R  J 

for  all  *...  J  1 

In  the  example  under  discussion,  ^  is  only  used  for  wj,  and  not  shared 
with  anything  else.  We  therefore  defer  consideration  until  later. 

t|*2  must  be  a  2  block  POC,  greater  than  ^  3  since  it  is  shared 
between  nj  and  *3,  and  must  have  BSS  elements  1  or  2.  (None  may  be 
0,  and  r^*3=rj’3=l.) 

♦1  3  -  (1,3)(2)(4)(5)(6,7)  ;  BSS  =  1  1  0  0  2 

10  111 

Since  no  BSS  element  may  be  greater  than  2,  and  there  may  be  only 
two  blocks  in  <|»2,  the  (1,3)  and  (2)  blocks  must  be  combined.  All 
resulting  *3  BSS  elements  are  1,  allowing  the  blocks  (4)  and  (5)  to 
be  assigned  to  either  of  the  other  two  blocks,  but  not  together.  Therefore, 

•  (1,2,3,4)(5,6,7)  or  *Z  •  (1 ,2,3,5)(4,6,7). 

2  2 

In  either  case,  BSS  =  2  2. 

2  2 

Thus  there  are  only  two  choices  for  <l<3  Is  examined  next. 

+3  performs  two  functions.  It  must  be  greater  than  or  equal  to  ^  3* 


since  it  is  shared  between  «2  and- *3.  In  addition,  together  with  ^ 
it  must  give  *3.  In  order  to  satisfy  these  constraints,  we  use  the 
following  information. 


*2j3  =  (13) (267 ) (4) (5 ) 


BSS  =  0  1  1  1 
1111 


.2.3  . 


r2  =  c2,3  r3 


2.3 


1 


From  these  numbers  we  can  see  that  any  two  blocks  may  be  brought 
together  in  one  block  of  ^  with  the  remaining  two  blocks  brought 
together  in  the  second. 

We  also  know  that 


*2^3  =  ((1  »3)(4)<2>)((5)(6,7))‘  and  =  ( (13) (5)<2>) ( (4) (6.7) ). 

-  .W  .S 

Each  of  these  quotients  tell  which  blocks  of  *3  must  be  separated 

by  *3  in  order  that  the  product  <j>2  •  ^3  will  give  *3. 

1  * 
Let  us  arbitrarily  choose  $  .  Then  there  are  two  choices  for 

2 


+1  -  (1 ,2,3,6,7)(4,5)  or 
3 


♦  =  (1 *3,5)(2,4,6,7) 
3 


Each  of  these  separate  (13)  from  (4)  and  (5)  from  (6,7)  and  are 
greater  than  <j»2  3  with  BSS  elements  of  1  or  2. 

Next,  we  examine  ^  must  be  greater  than  i|*2  4- 


*2,4  "  0 »2,4,7)(3)(5)<6>  ;  BSS  =  2  0  1 

1  1  0 

Since  all  BSS  elements  must  be  1  or  2,  there  is  a  unique  compatible.. 
*4  =  (1 »2,4,7)(3,5)<6>  . 

The  product  of  the  two  possible  ^s  and  ^  are  now  checked. 
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w,  «  (2,7) (4 ) (5.)  <1,3,6>  *J-*4  =  (127) (3) (4) (5) <6>. 


*2  4s*3  -*4  -  (1 ) (3 ,5) (2 ,4 ,7) <6>. 

Failure  of  these  products  with  respect  to  ir2  means  that  we  must 

2 

backtrack  to  any  previous  choice.  Thus  we  must  consider  \fi  =  (1 ,2,3,5)(4,6,7). 

2  ^ 

Using  <|>  /*3  and  ^  3  found  above,  we  have  two  choices  for 


*  -  0.3,4)(2,5,6,7)  or 

3 


*  *  (1,3,2,6,7)(4,5). 

3 


Only  one  <|>4  is  available  from  the  above  computation.  Thus  we  again 
compare  the  products  43  - and  **  *  <|»4  with  *2,  and  again  find 

»2  ^  ^  •  ^4  and  w2  ^3  *  *4 


No  other  choices  were  made  in  the  evaluation  of  this  possible  profile. 

Therefore  there  is  no  minimum  table  entry  substring  encoding  with  this 
profile. 

The  next  step  is  to  backtrack  in  the  formation  of  a  possible  profile. 
None  of  u4,  ir3,  or  ^  can  move  further  to  the  right  under  the  pairwise 
compatiblity  constraints,  therefore  must  be  moved.  The  possible 
profile  pp7  in  Figure  11  is  obtained  by  placing  w2,  *3,  and  w4  in  the 
leftmost  permissible  position.  This  possible  profile  must  be  evaluated 
next. 


First  y*|  must  be  formed  from  4-,  which  was  observed  above  to  have 
a  single  completely  compatible  PDC,  ^  =  (1 ,2,4,7)(3,5)<6>.  Since  *4 
no  further  product  check  needs  to  be  done  on  the  fourth  row.  ^1^2  = 
( (2 ,7) (4) <1  >  )((5)<3>).  Therefore  there  are  four  choices  for 
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-  -VU 

J  =  (1,2,3,5,7)(4)<£> 

2 

*2  =  0,4)(2,3,5,7)<6> 

2 

4^  is  also  constrained  by 

♦,f2  -  (1,3)(2,7)(4)(5)(6)  ; 

(1,3)  and  (2,7)  must  be  in  different  blocks  of  Therefore,  only 
satisfies  both  the  product  and  sum  constraints,  with  <6>  added  to 

2 

(1 ,3,4,5)  to  satisfy  complete  compatibility. 

**  *  ^  =  0»3,4,5,6)(2,7). 

*3  is  found  next.  =  ((1,3)(6)<4*,5>)((2}(7)).  Therefore  *3  must 

be  either: 

4,1  *  (1 »2,3){6,7)<4,5>  or  *2  *  (1 ,3,7)(2,6)<4,5>. 

3  3 

4*3  must  also  be  completely  compatible  with  ^  3. 

*T#3  -  (1,3)(2)(4)(5)(6,7)  ;  BSS  =  1,1. 0,0,2 

1.0,1 .1.1 

From  ^  3,  blocks  (1,2,3)  and  (6,7)  must  be  in  different  blocks  of 
*3,  leaving  only  *3  .  However,  (4)  and  (5)  must  be  assigned  to  make 
*3  completely  compatible  with  ^  3. 

The  possibilities  are: 


*3  =  (1,2,7)(3,4,5)<6> 
2 

/  =  (1 ,3,4,5)(2,7)<6>, 
2 


BSS  *  1 ,2,0, 0,1 
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^  e  (1t2i3i4)(S|6t7)  or  ^  *  (1 *2»3»5)(4,6»7). 

Finally*  fyneed  only  satisfy  the  quotient  of  .  There  are  a 

number  of  choices  since 

*■***--  ~ 

*p*3  *  (0»3)(4)<2>)((5)(6,7))  and  <j£/ir3  =  ((1 ,3) (5) <2 >) ( (4) (6 ,7) ) . 

Let  us  chose  one  possibility,^  and  *  (1 ,2,3,5) (4,6,7). 

Summarizing  the  ^'s  obtained: 


*3  *  (1.2.3,4)(5,6,7) 

*4  -  (1 ,2,3,5)(4,6,7) 

in  This  must  be  placed  in  such 

a  way  that  it  does  not  become  a  block  of  its  own  in  any  product  involving 
f  (Remember  that  a  product  check  is  a  necessary  but  not  sufficient  condi 
tionfor  a  solution.  The  only  product  in  which  is  involved  is 

*2  ss  W  For  a  solution  *2  ss  Pl‘P2*  °2  =  *2  s1nce  there 
are  no  don't-cares  in  *2. 

»2/p2  *  ((4)(5)<1 ,3,€ >}((2,7}).  Therefore  the  <6>  must  be 
placed  either  with  (4)  or  (5)  In  p,  to  prevent  a  separate  block  (6) 

In  the  product.  Since  (4)  or  (5)  are  in  both  blocks  of  <6> 
can  go  into  either  block.  Let  us  choose  the  first  block. 

Our  final  results  are 

P,  «  (1.2,4,6.7)(3,5) 

P2  «  (1 ,3,4,5,6)(2,7) 

P3  -  (1,2,3,4)(5,6,7) 

*4  ■  (1 ,2,3,5)(4,6,7). 


*,  *  (1,2,4, 7)(3,5}<5> 

*2  -  (1 ,3,4,5,6)(2,7) 

There  still  remains  one  don't-care 
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To  produce  a  state  encoding  and  a  set  of  tables,  binary  values 
must  be  assigned  to  the  blocks  of  the  ps.  One  arbitrary  choice  is 


P1  P2  p3  P4 
1  0  0  0  0 

state  2  0  10  0 

3  1.  0  0  0 


4  0  0  0  1 

5  10  10 

6  0  0  1  1 

7  0  111 


encoding 


Input  1  0110 

Input  2  1100 

Input  3  0011 

Input  4  1000 


profile 


From  the  above  and  the  original  state  table,  the  tables  of  Figure  4 
are  built  in  a  straight  forward  manner. 
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Fig.  1.  Conceptual  state  table  representation. 

Fig.  2.  Example  state  table. 

Fig.  3.  State  encoding  and  input  substrings  for  example. 

Fig.  4.  Realization  for  example. 

Fig.  5.  Hardware  implementation  of  interpreter. 

Fig.  6.  PL/I  implementation  of  interpreter. 

Fig.  7.  Input  PDCs,  input  table  partitions,  state  encoding  and 
input  substrings  using  encoding  algorithm  I. 

Fig.  8.  Input  table  partitions  of  Fig.  3. 

Fig.  g.  Upper  bounds  of 

Fig.  10.  Compatibility  statistics  for  the  upper  bounds  of 
Fig.  11.  Possible  Profile  Search  Trees. 


TABLE  LAYOUT  OF  FSM 


I 


Fig.  1,  Conceptual  state  table  representation 


Yl  Y2  Y3  Y4 

1 

0  0  0  0 

2 

0  10  0 

>1!  y2y3 

3 

10  0  0 

I2!  Y]Y2 

4 

0  0  0  1 

>3:  Y3^ 

5 

10  10 

II,:  yx 

6 

7 

0  0  11 

0  111 

SUBSTRINGS 

STATE  ENCODING 


Fig.  3.  State  encoding  and  new  substrings  for  example 


Fig.  5.  Hardware  implementation  of  interpreter. 


FSM:  PROCEDURE  (I); 

DCL  FIRST  BIT  (1:4)  BINARY  (16)  INIT  (2,1, 3,1), 

LENGTH  (1:4)  BINARY  (16)  INIT  (2, 2, 2,1), 

SUBTABLE  (1:4)  BINARY  (16)  INIT  (0,4,7,11), 

NEXT  STATE  TABLE  (0:12)  BIT  (4)  INIT 

('1000'B,  ' 1010'B,  'OQOQ'B,  '1010'B, 

'1010'B,  '0011 1 B,  'OOOl'B, 

'OOOl'B,  '1000'B,  'OOOl'B,  'lOOO’B, 

'OlOO'B,  '1010'B), 

OUTPUT  TABLE  (0:12)  LABEL  INIT 
T"  A,A,A,B, 

A,  A  ,A , 

A,B,B,A, 

A,A  ), 

STATE  BIT  (4), 

INDEX  BINARY  (16), 

I  BINARY  (16); 

INDEX  *  SUBTABLE  (I)  +  SUBSTRING(STATE,FIRST_BIT(I) ,  LENGTH(I)) 

STATE  *  NEXT  STATE  TABLE( INDEX); 

GOTO  OUTPUT_TABLE( INDEX); 

A:  /*  output  routine  A  */ 

RETURN; 

B:  /*  output  routine  B  */ 

RETURN; 

END; 


Fig.  6.  PL/I  implementation  of  interpreter. 


(1 »3)(2)(6)(7)<4,5> 
(2,7) (4) (5)<1 ,3,6> 
(1 *3)(4)(5)(6,7)<2> 
(1 ,2,4)(3)<5,6.7> 


input  POCs 

T]  *  (1,3,4)(2,5)(6)(7) 

t2  =  (1 ,2,7) (3,4)(5,6) 

t3  =  (1 ,2,3)(4)(5)(6,7) 

t4  *  (1,2,4, 5X3.6.7) 

Input  table  partitions 


t  E(TlV3T4} 

y,  y2  y3  y4  y5  y6  y7 

1  0  0  0  0  0  0  0 

2  0  1  0  0  0  0  0 

3  0  0  0  1  0  0  1 

4  0  0  0  1  0  1  0 

5  0  110  10  0 

6  10  10  111 
7  110  0  111 

state  encoding 


Jl!  ^1^2 

V  V« 

T3:  Vg 

V  y7 


E(t,) 

E(t2) 

E(t3) 

E(t4> 


Fig.  7.  Input  TOCs,  input  table  partitions,  state  encoding 

AM)  INPUT  SUBSTRINGS  USING  ENCODING  ALGORITHM  I. 


BSSs 


(1,2,3)  (4,5,6){7,8,9) 

<10,11> 

(1, 2,3,8)  (4,5,6)  (7,9) 

<10,11> 

(1,2,3)  (4, 5, 6, 8)  (7,9) 

<10,11> 

(1 ,2,3,7)  (4,5,6)  (8,9) 

<10,11> 

(1,2,3)  (4, 5, 6, 7)  (8,9) 

<10,11> 

(1 ,2, 3, 7, 8)  (4, 5, 6, 9) 

<10,ll> 

(1,2, 3,9)  (4, 5, 6, 7,8) 

<iu,n> 

1,2,2 

2,1,1 


1.3.1 

2.1.1 


Fig.  9.  Upper  bounds  of  *  +* 
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Abstract 

Finite-state  techniques  are  applied  to  the  specification  of  the  control  portion 
of  a  program.  A  language,  an  implementation  representation,  and  an  optimization 
are  described. 


1.  INTRODUCTION 

The  problem  of  software  design  and  engineering  is 
with  us  at  all  levels  of  system  size,  from  the  mi¬ 
crocomputer  to  the  complex  megacomputer  system. 

One  facet  of  software  system  design  that  seems  to 
lend  Itself  to  a  similar  solution  regardless  of 
size  is  that  of  control.  At  the  microcomputer 
level,  control  of  a  hardware  system  or  peripheral 
Is  often  the  primary  function  of  the  microcomputer 
as  a  result  of  an  ever  decreasing  crossover  point 
in  the  cost  of  a  microcomputer  compared  to  a  TTL 
controller  (lj.  At  the  other  end  of  the  size 
spectrum  large  systems  often  contain  significant 
control  programs  or  executives  in  addition  to 
their  host  operating  systems,  as  well  as  lower 
level  I/O  control  routines  {2,3).  This  paper  ex¬ 
amines  the  application  of  finite  state  techniques 
in  a  set  of  programs  designed  to  form  the  nucleus 
of  a  software  engineering  system  to  allow  "high- 
level"  specification  of  control  programs  and  auto¬ 
matic  conversion  to  efficient  program. 

2.  FINITE  STATE  SPECIFICATION  LANGUAGE 

A  finite  State  Specification  Language,  F1SSL,  has 
been  implemented.  The  primary  objective  of  this 


language  is  to  enhance  the  user's  ability  to  spec¬ 
ify  a  finite  state  machine  naturally  and  efficient¬ 
ly,  and  to  understand  its  operation  once  specified. 
An  intermediate  representation  of  the  machine  is 
stored  on  disk  to  serve  as  input  to  the  optimizer 
and  other  system  programs. 

The  language  is  interactive.  In  which  statements 
are  interpreted  line  by  line  to  modify  the  finite 
state  machine  as  so  far  described.  The  language 
interpreter  responds  either  with  a  diagnosis  of 
error,  or  to  obtain  clarification  of  allowable  am¬ 
biguities.  For  example,  the  use  of  a  non-existent 
state  would  be  an  error,  but  the  respecification 
of  a  table  entry  may  or  may  not  be  intended  by  the 
user,  so  that  clarification  must  be  requested. 

The  main  features  of  the  language  are  as  follows. 
Numbers  in  parentheses  indicate  line  murders  in 
Figures  1,  3,  and  5.  There  is  a  declaration  state¬ 
ment  to  provide  FISSL  with  disjoint  sets  of  nares 
for  the  inputs,  states,  and  outputs  of  the  finite 
state  machine  (1,  2,  3).  The  sets  of  names  are 
kept  disjoint  in  order  to  avoid  ambiguity  without 
demanding  an  ordering  of  names  by  type  or  use  of 
type  identifying  keywords  in  the  language  state- 
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■tents.  The  statements  for  the  specification  of 
the  finite  state  machine's  table  entries  are  com¬ 
pact  yet  logically  clear.  The  primary  statement  is 
FOR  <condition  list>  DO  <tablp  entry> 

The  condition  list  indicates  in  a  very  flexible 
way  which  entries  in  the  table  are  to  be  specified 
by  this  statement.  A  single  entry  (4),  an  entire 
row  or  column  (5),  a  set  of  entries  produced  by 
taking  the  cross  product  of  a  subset  of  states  and 
a  subset  of  inputs  (6),  or  the  union  of  several  of 
tnese  (11)  may  be  easily  specified.  In  addition 
an  ALLBUT  operator  (9)  allows  easy  specification 
of  very  large  subsets.  DC  (5,7)  indicates  that  an 
entry  is  to  be  left  unspecified.  The  table  entry 
part  of  the  statement  may  be  a  state  (10),  an  out¬ 
put  (11),  or  a  state  and  an  output  (6).  If  the 
state  or  output  is  omitted,  it  is  left  unspecified 
or  with  any  previously  specified  value.  Fig.  2 
shows  the  state  table  specified  by  (1)  to  (13). 

Another  important  feature  of  FISSL  that  allows  com¬ 
pact  specification  is  the  ability  to  specify  com¬ 
pound  state  names.  A  state  may  be  divided  into 
several  substates  (16),  each  of  which  has  a  set  of 
names  declared  for  it  (17,18).  The  cross  product 
of  these  sets  of  names  is  the  machine's  state  set. 
Therefore,  SI  becomes  twelve  states,  named  H.ST, 
H.TX,  ....  T.ST,  ....  TT.SYN2. 

If  one  or  more  of  the  substate  names  is  omitted  in 
specifying  the  state  in  the  condition  list,  then 
all  possible  values  are  used  for  the  omitted  sub¬ 
states  in  determining  the  table  entries  to  be  spec¬ 
ified.  For  example, in(21),  (TX.ST)  specifies 
states  H.Ta,  T.TX.  TT.TX,  H.ST,  T.ST,  and  TT.ST. 

In  the  table  entry  part,  TX  Indicates  that  the  D 
substate  becomes  TX.  If  the  P  substate  is  unspec¬ 
ified  in  the  table  entry  then  no  change  in  its 
specification  is  made.  If  SAME  P  is  specified  how¬ 
ever,  P  is  specified  to  remain  the  same  in  the 
next-state  as  in  the  present  state.  Thus  in  (21) 
H.ST  has  a  next  state  of  H.TX,  while  T.ST  has  a 
next-state  of  T.TX. 

Fig.  3  specifies  the  state  behavior  of  a  Half  Du¬ 
plex  Non-switched  Multipoint  Oata  Communication 
System  originally  presented  by  Bjorner  (3).  Fig.  4 


shows  the  resulting  state-  table. 

A  quite  significant  extension  is  the  addition  of 
procedure-like  statements.  The  term  procedure-like 
is  used  because  they  do  not  specify  a  procedure 
that  is  used  at  run  time,  but  at  compilation  time 
to  build  the  state  table.  It  is  primarily  built 
around  a  CASE  statement.  Fig.  5  gives  a  specifi¬ 
cation  that  is  easily  seen  to  be  structurally  iden¬ 
tical  to  a  decision  process  in  a  typical  branching 
program. 

Note  that  statement  grouping  is  achieved  by  DO  and 
0D.  and  all  CASE  statements  have  explicit  ELSEs. 

The  state  may  be  modified  anywhere,  and  output  may 
be  specified  anywhere.  Outputs  become  more  complex 
if  more  than  one  output  is  encountered  in  reaching 
the  lowest  level  of  nesting.  ERROR  indicates  that 
an  error  indication  should  be  put  in  the  state 
table  and  no  further  processing  should  be  done  on 
this  path  through  the  specification.  Only  the  sub¬ 
states  encountered  with  an  explicit  next  state  are 
specified.  If  a  substate  is  not  encountered  in 
the  table  entry  part,  it  remains  unspecified,  un¬ 
less  listed  as  a  parameter  of  SAME.  In  (73)  SAME 
REMAINING  specifies  that  any  substates  not  changed 
in  the  scope  of  the  DO  in  (46)  is  to  remain  the 
same  as  it  is  specified  in  the  condition-list.  For 
example,  the  entry  at  II,  A2.B2.C3.D1.E2  receives 
explicit  next  state  specification  of  A1.B3.C2.  0 

and  E  remain  to  be  specified,  therefore  they  be¬ 
come  D1.E2. 

The  state  table  is  built  by  the  compiler  by  repeat¬ 
ed  execution  (simulation)  of  the  specification. 

The  STATE  set  is  the  only  one  broken  into  sub¬ 
states  here.  Similar  methods  may  be  used  for  the 
INPUT  set.  Note  however  that  the  OUTPUT  set  has 
been  implicitly  changed  by  allowing  more  than  one 
output  to  appear  on  a  path  through  the  nested  CASE 
statements.  For  example,  state  A4.B2.C3.D2.12  has 
an  output  of  04,05,02.  Thus  the  actual  outputs  are 
ordered  subsets  of  the  specified  OUTPUT  set. 

3.  REPRESENTATION  OF  A  FINITE-STATE  MACHINE 
This  section  assumes  that  a  finite-state  machine 
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has  been  produced  and  has  been  reduced  so  that  no 
states  are  equivalent.  The  task  is  now  to  code 
this  machine  into  a  format  capable  of  being  loaded 
into  a  random  access  or  read-only  memory.  An  ef¬ 
ficient  storage  consuming  coding  for  the  machine 
is  desired.  A  table  representation  will  be  used 
since  tables  may  be  stored  in  random  access  mem¬ 
ories  efficiently  and  because  multi-way  branching 
can  be  easily  achieved.  Fig.  7  shows  a  conceptual 
interpreter  and  table  implementation  of  a  finite 
state  machine.  An  input  causes  the  present  state 
to  be  read  from  state  storage.  A  mapping  function 
on  the  input  and  present  state  form  an  index  into 
the  table  containing  the  next-state  and  output 
functions.  The  next-state  is  read  from  the  table 
and  written  into  state  storage,  while  the  output 
is  used  appropriately,  usually  as  an  address  or 
routine  to  be  called,  for  a  large  system,  or  as  a 
binary  word  to  be  placed  on  a  peripheral  bus  in  a 
micro-computer  system. 

The  method  considered  in  this  paper  decomposes  the 
finite-state  machine  into  a  sub-table  per  input, 
with  an  additional  table  of  pointers  to  these  sub¬ 
tables.  The  decomposition  of  the  table  into  input 
sub-tables  gives  an  opportunity  for  memory  savings 
It  is  assumed  that  the  next-state  and  output  en¬ 
tries  are  either  both  specified  or  both  don't  care. 

If  the  input  is  known,  then  there  is  redundancy  in 
the  information  provided  by  the  state.  For  exam¬ 
ple,  it  is  never  necessary  to  identify  a  state 
whose  entry  is  don't  care,  nor  is  it  necessary  to 
distinguish  between  two  states  with  the  same  en¬ 
tries.  Providing  memory  locations  for  this  redun¬ 
dant  information  is  wasteful.  A  state  encoding 
scheme  that  would  allow  identification  of  a  unique 
entry  In  the  sub-table  is  desirable.  That  is,  the 
original  finite-state  machine  should  be  trans¬ 
formed  to  a  table  with  only  one  occurrence  of  each 
distinct  entry  in  each  input  sub-table. 

Fig.  2  is  a  finite-state  machine  with  four  inputs, 
1  through  4,  seven  states,  A  through  G,  and  two 
outputs, X  and  Y.  The  input  sub-table  correspond¬ 
ing  to  1  must  contain  four  entries,  one  for  each 
AX,CX,EX  and  EY.  Similarly,  the  4  sub-table  must 


contain  2  entries.  The  state  number  no  longer  pro¬ 
vides  a  direct  index  to  the  sub-tables.  For  exam¬ 
ple,  if  the  machine  is  in  state  G  and  input  1  is 
received,  there  is  no  7th  entry  in  the  1  sub-table. 

A  mapping  algorithm  from  the  state  to  the  input 
sub-table  indices  is  needed.  The  method  adopted 
here  for  its  simplicity  of  use  is  to  encode  the 
states  using  binary  variables  y^y--*^,,  such  that 
for  each  input  there  exists  a. substring  of  these 
binary  variables  which  can  be  used  as  an  index  into 
the  corresponding  input  sub-table.  Fig.  8  shows  an 
appropriate  encoding  of  the  states  of  Fig.  2.  Since 
the  1  sub-table  has  four  entries,  the  1  substring 
should  have  four  distinct  codes,  which  arc  00,  01, 
10,  and  11  under  variables  V-fiy  Note  that  the  2 
substring  y^y?  has  exactly  3  values.  In  addition, 
values  of  y^y2  for  any  two  states  are  the  same  if 
and  only  if  the  entries  of  those  two  states  are  the 
same  or  one  or  both  is  don't-care  under  2  in  Fig. 2. 
Thus  states  A  and  D  have  the  y^  value  00.  Under 
input  2  State  A  is  don't-care  and  state  0  is  EX. 

Fig.  9  shows  the  tables  which  ultimately  realize 
the  machine  of  Fig.  2. 

The  interpreter  for  the  substring  encoding  is  ei¬ 
ther  software  or  a  circuit  which  masks  the  appro¬ 
priate  bits  for  each  input,  shifts  them  to  the 
right,  and  uses  them  as  an  index  into  the  subtable. 
By  using  such  a  circuit  or  software,  there  is  little 
custom  designed  circuitry,  none  in  the  case  of  the 
software  interpreter,  and  a  circuit  amenable  to 
possible  LSI  Integration  with  only  the  final  mask 
and  shift  quantities  to  be  determined  for  the  indi¬ 
vidual  state  table,  perhaps  to  be  loaded  into  a 
Read  Only  Memory.  This  implementation  has  the  im¬ 
portant  property  that  the  input  sub-table  lookup 
constitutes  a  multiway  branch  to  the  output  routine, 
which  gives  good  real-time  characteristics,  and  is  in 
fact  a  major  reason  for  the  representation  chosen. 

4.  STATE  TABLE  OPTIMIZATION  PROGRAM 

A  State  Table  Optimization  Program  (STOP)  has  been 
written  which  compacts  a  state  table  into  a  set 
of  minimal  input  sub-tables.  The  optimization  de¬ 
pends  on  the  finding  of  an  appropriate  encoding 
having  a  substring  for  each  subtable.  Such  an  on- 
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coding  ilmys  exists  but  it  may  have  more  than  the 
■inimun  number  of  bits  necessary  to  uniquely  en¬ 
code  the  state  set.  The  encoding  used  above  uses 
♦  bits  rather  than  the  3  bits  necessary  to  unique¬ 
ly  specify  7  states.  STOP  is  written  to  find  the 
atniaua  bit  encoding  for  minimum  entry  input  sub¬ 
tables. 
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Abstract 

This  paper  examines  the  use  of  finite  state 
techniques  in  a  general,  rather  than  application 
specific,  context.  It  discusses  applicability, 
benefits,  and  trade-offs,  as  well  as  techniques 
for  embedding  then  in  an  overall  system.  It 
presents  a  specification  language  and  a  table 
optimisation  pregrar.  which  are  tools  for  the  use 
Of  these  techniques. 


The  problem  of  software  design  and 
engineering  is  with  us  at  all  levels  of  system 
•lze,  from  the  microcomputer  to  the  complex 
■egacomputer  system.  One  facet  of  software  system 
design  that  seems  to  lend  itself  to  a  similar 
solution  regardless  of  size  is  that  of  control. 
At  the  microcomputer  level,  control  of  a  hardware 
system  or  peripheral  is  often  the  primary  function 
of  the  microcomputer  as  a  result  of  the  ever 
decreasing  crossover  point  in  the  cost  of  a 
microcomputer  compared  to  a  TIL  controller  [1]. 
At  the  other  end  of  the  size  spectrum,  large 
systems  often  contain  significant  control  programs 
or  executives  in  addition  to  their  host  operating 
systems,  as  well  as  lower  level  1/0  control 
routines  [2,3].  This  paper  .examines  the 
application  of  finite  state  techniques  in  several 
programs  designed  to  fora  part  of  a  software 
engineering  system  to  allow  high  level 
specification  of  control  functions  and  automatic 
conversion  to  efficient  programs. 

Many  papers  have  appeared  in  the  literature 
la  the  past  decade  describing  the  use  of  a  finite 
state  machine  as  an  integral  part  of  a  computer 
program.  Among  the  authors  and  applications  were 
Belstand  [2],  an  executive  system  with  a  complex 
control  and  decision  structure,  Johnson  et.  al. 
m.  lexical  analysis,  Killer.son  [5],  the  control 
of  psychological  experiments,  and  Birice  (3]  and 
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BJorner  [6],  teleprocessing  device  control  and 
protocols.  Each  of  these  papers,  describes  a 
specific  use  of  a  finite  state  machine,  and 
explains  to  some  extent  the  characteristics  that 
make  a  finite  state  machine  suitable. 

A  primary  motivation  in  these  papers  for  the 
use  of  finite  state  naehir.es  is  their  convenience 
for  describing  complex  processes.  Each  was  then 
transformed  into  the  implementation  that  the 
author  had  determined  was  the  most  efficient 
according  to  the  application’s  objectives.  In 
nost  cases  the  specification  of  the  finite  state 
aachine  was  an  exact  and  reasonably  understandable 
one. 

It  is  the  purpose  of  this  paper  to  consider 
the  use  of  finite  state  machines  from  a  mere 
general  point  of  view.  In  taking  this  point  cf 
view,  the  paper  concentrates  on  the  benefits, 
trade-offs,  and  practical  considerations  involved 
in  order  to  make  the  usefulness  of  the  finite 
state  cachine  in  a  given  application  mere 
generally  answerable  than  simply  matching  the 
application  against  the  examples  previously 
presented  in  the  literature. 

The  paper  presents  a  high  level,  compact, 
efficient  language  for  the  specification  of  a 
finite  state  machine,  as  well  as  an  optimization 
program  for  a  broad  class  of  implementations. 

A  recent  paper  by  Salter  [7]  presents  another 
general  approach  to  the  use  of  finite  state 
machines  as  part  of  a  decomposition  methodplov y. 
This  paper  takes  a  similar  approach  to  Salter,  but 
describes  it  from  a  different  point  of  view, 
including  more  specific  language  and 
implementation  detail. 

Applicability  &£  Finite  State  Machines 

Many  stored  program  systems  arc  programmed  to 
respond  to  an  input  from  a  single  source  or  from 
one  of  s  elarfs  of  sources  in  the  following  manner. 
A  stored  indication  of  the  past  history  of  the 
Input  source  and  the  present  input  are  used  to 
determine  some  action  to  be  taken  and  en 
appropriate  updating  of  the  historical  record  to 
be  made.  In  many  cases  the  historical  record  has 
fixed  size,  and  does  not  grow  with  the  length  of 
tbs  input  string,  (number  of  Inputs  received  over 


time)  leading  to  an  informal  characterization  of 
such  a  system  as  a  finite  state  machine. 

Such  systems  are  often  Implemented  by 
assigning  variables  to  various  facets  of  the 
historical  record,  usually  in  a  Banner  that  is 
primarily  understood  by  the  programmer  rather  than 
efficiently  utilized  by  the  machine.  The  entire 
historical  record,  or  state  if  we  apply  finite 
state  machine  terminology,  is  contained  in  oany 
such  variables.  For  a  problem  of  fcr.y  corplexity, 
the  program  to  respond  to  tha  receipt  of  an  input 
does  not  decide  on  the  action  to  be  taken  in  a 
single  N-ary  decision,  but  usually  branches 
through  a  sequence  which  examines  one  variable  or 
relationship  between  variables  at  a  tiae,  making 
binary  decisions  along  the  way.  On  the  other 
hand,  an  11  state  finite  state  machine  may  be 
considered  to  cake  a  single  N-ary  decision  on  each 
input  received. 

If  only  a  finite  amount  of  historical  record 
Bust  be  kept  regardless  of  the  length  of  the  input 
sequence,  then  the  historical  record  say  be 
considered  to  te  a  state  initialized  to  some 
Initial  value  SCO).  At  each  input  or  event  the 
next  state  (the  new  value  cf  the  state  to  be 
recorded)  is  a  function  cf  the  current  event  and 
the  present  state,  NS(X,S).  Similarly,  the  output 
St  each  event  becomes  a  function  of  the  current 
event  and  present  state  0(X,S).  These  event 
oriented  characteristics  cay  te  inherent  in  the 
system  or  they  cay  be  imposed  by  choice  in  a 
decomposition  process.  For  example  the 
Sppllcation  to  lexical  analysis  [4]  breaks  up  the 
input  string  into  discrete  characters,  between 
which  a  state  is  stored.  The  decomposition  of  a 
problem  into  discrete  sequential  steps  in  this 
Banner  allows  virtually  any  program  to  be  cast  as 
S  finite  state  machine  or  a  set  of  finite  state 
machines. 

HaUatlaa  lac  ifaa  lias,  si  Finite  Slals.  icctmiflufia 

The  benefits  derived  from  the  use  of  finite 
State  techniques  fall  into  two  classes,  those  that 
contribute  to  the  case  of  specification  and 
testing  of  a  system,  and  those  that  contribute  to 
laplexentation  efficiency. 

Finite  state  techniques  contribute  to  the 
eaae  of  specification  since  they  enable  the 
description  of  the  control  of  a  system  at  a  higher 
level  than  a  direct  programmed  implementation  of 
the  control.  They  are  at  least  one  level  of 
abstraction  above  a  programmed  specification.  In 
addition,  it  is  possible  to  carry  over  most 
techniques  of  the  multiple  levels  of  abstraction 
Bethodologies  [8]  into  finite  state  techniques. 
This  carryover  is  not  described  here,  but  is  the 
subject  of  continued  work. 

The  behavior  of  a  finite  state  machine  is 
easy  to  simulate  prior  to  the  availability  of  the 
detailed  implementation  of  the  machine  itself  and 
the  subroutines  which  it  calls.  Therefore 
simulation  testing  of  the  system  at  a  high  level 
aay  begin  as  soon  as  the  finite  state  nachlne(s) 
has  been  specified.  Since  the  finite  state 


aachlnc  will  oc  automatically  transformed  into  its 
implementation,  a  hlGh  level  of  confidence- Trt--the 
implementation  is  possible  after  the  simulation 
has  been  thoroughly  tested.  Of  course,  this 
confidence  docs  not  extend  to  the  subroutines 
unless  they  too  arc  specified  in  a  manner  auto¬ 
matically  translatable  into  their  implementation. 


The  primary  implementation  efficiency  to  be 
gained  by  these  techniques  is  reduced  decision 
tine.  The  sequential  decision  process  described 
above  requires  nar.y  binary  decisions.  Consider  a 
very  regular  program  graph,  Figure  1,  with  k 
decisions  in  each  path  through  the  program. 
Assume  that  this  program  is  run  in  response  to  one 
of  the  inputs  to  the  system.  Then  this  program  is 
equivalent  to  one  input  column  of  a  state  table. 
Each  node  in  the  graph  labeled  with  a  D  represents 
a  decision,  or  branch,  while  updating  of  the  state 
and  output,  marked  with  Ns  and  Os,  are  done  after 
all  decisions  have  been  cade.  In  Figure  1,  k  is 


it- 


•  .  If  *  constant  tin*  expenditure  Is  assumed  for 
both  the  decision  ol  the  program  and  the  N-ary 
decision  (state  table  lookup)  of  the  finite  state 
•acblne,  then  the  finite  state  machine  uses  time  a 
factor  of  k  less  than  the  binary  decision 
structure.  In  a  program  not  so  regular  in 
structure,  there  Is  seme  average  number  of 
decisions  per  entry  into  the  pr ceres.  In  such  a 
esse  the  time  savings  is  this  average  number. 
Figure  2  snows  a  typical  graph,  actually  produced 
t>r  the  author  as  part  of  a  commercial .  telephone 
system.  In  addition  to  points  of  branching.  It 
also  Includes  points  of  Joining.  Some  of  the  exit 
points  arc  marked  p=3,  meaning  that  this  exit  is 
provided  as  a  defensive  technique,  and  not 
normally  ured.  If  all  other  paths  are  equally 
likely,  there  is  an  average  k  of  6  2/3- 

Tice  may  also  be  saved  in  recording  the  next 
state,  since  there  will  be  only  one  updating  of 
the  state,  using  the  value  read  from  the  state 
table.  A  multiple  variable  state  will  usually  be 
updated  at  several  different  points  in  the 
program.  The  N's  and  0's  in  Figure  2  indicate 
points  of  updating  the  state  and  performing 
output,  respectively.  Thus  the  state  is  updated 
In  2  2/3  places  on  the  average  entry  into  the 
program . 

The  remaining  aspect  of  the  entire  process  is 
the  output.  No  time  ear.  be  saved  here,  since  the 
output  rust  be  performed  regardles  of  the  decision 
structure. 

The  final  benefit  obtained  is  the  potential 
use  of  formal  techniques  in  the  coding  and 
optimization  process.  Techniques  are  available 
from  the  current  body  of  switching  theory  or  may 
be  newly  developed  for  the  special  characteristics 
of  program  embedded  finite  state  machines.  These 
techniques  arc  all  decidable,  although  costly, 
which  Is  not  the  case  for  general  program  schema. 

As  an  example,  existing  techniques  Include 
state  reduction  [9],  The  techniques  which  exist 
must  be  tempered  by  practicality.  Host  seek  an 
optimal  solution  at  the  expense  of  computation 
time  and  in  general  say  net  handle  machines  as 
large  as  the  or.e3  which  will  result  from  the  use 
of  finite  state  techniques  in  programming. 
However,  modifications  which  produce  "good" 
reductions  with  moderate  expenditure  of 
computation  time  should  be  achievable. 

A  newly  developed  technique  described  below 
110]  finds  an  optimal  memory  consuming 
implementation  which  still  preserves  .  the  N-ary 
branch  property  of  a  finite  state  machine. 


Bubctfdlnis  a  finite,  state  Machine  In  &  System 

Some  previous  work  Involving  finite  state 
machines  in  the  programming  process  cay  be 
described  as  the  replacement  of  specific 
subroutines  at  a  relatively  low  level.  Hlrke's 
device  control  programs  [3],  BJorner's  protocols 
[6],  and  Johnson's  lexical  processors  t**J  cay  he 
so  described.  On  the  other  hand,  in  Hclstand's 


executive  system  [2]  the  finite  state  machine  was 
the  higher  level  decision  raker,  arid  the  remaining 
systrn  proceed 3  were  called  as  subroutines  by  the 
finite  state  machine.  Tnc  approach  here  is  closer 
to  the  latter. 

Finite  state  machines,  vlth  appropriate 
supporting'  programs  and  algorithms,  form  the 
highest  level  of  decision  r.3kers.  The  state 
should  include  sufficient  information  for  the 
decision  made  to  be  a  significant  part  of  the 
system's  decision  process.  The  finite  state 
machine  calls  specific  programs  as  output.  feme 
of  these  output  programs  r.ay  be  finite  state 
machines  as  well,  resulting  in  a  hierarchical 
system.  As  an  example,  Heist aid's  executive  could 
call  Birke's  device  control.  In  addition,  should 
the  system  complexity  be  such  that  a  single  finite 
state  machine  becomes  too  large,  then  several 
communicating  finite  state  machines  at  the  same 
level  of  hierarchy  cay  be  used.  Such  a 
decomposition  often  arises  naturally  along  the 
usual  system  codule  divisions. 

The  classical  definition  of  a  finite  stale 
machine  includes: 

a  finite  set  of  states,  S, 
a  finite  set  of  inputs,  X, 
a  finite  set  of  outputs,  2, 
a  next-st2te  function,  KS(x,r),  mapping 
X  and  S  onto  S,  and 
an  output  function,  C(.r,s),  capping 
X  and  S  onto  Z. 

In  order  to  allow  the  use  of  such  a  machine 
in  a  programming  context,  several  additions  must 
be  made  to  this  definition.  The  first  addition 
arises  from  the  fact  that  all  informal: rn  used  by 
a  program  should  not  be  considered  stale 
information.  State  information  should  be 

restricted  to  that  needed  for  the  next-state  and 
output  decisions  to  be  made.  Information  needed 
by  the  system,  but  not  lor  these  functions,  should 
not  be  allowed  to  expand  the  state  set.  Inic- 
infornaticn  is  referred  to  as  Task  Tata,  rr.d 
represented  by  the  set  D.  An  example  '  r  task  dura 
is  the  identification  of  a  specific  devj',-. 
Without  such  information,  no  communication  to  tnc 
specific  device  could  be  performed.  However,  it 
is  not  needed  to  decide  what  actions  to  perform  in 
response  to  an  input  from  that  device. 

The  addition  of  task  data  allows  the  remov-l 
of  part  of  a  system’s  function  from  the  classical 
finite  state  machine  definition  for  rensens  cf 
efficiency.  Further  removal  m.3y  he  achieved  by 
allowing  the  finite  state  machine  to  uve 

■algorithmic  processes"  where  there  ore  tier.- 

efficient  in  specifying  and  performing  the 

system's  function.  For  example,  consider  a 
counting  function,  as  in  resource  allocation.  / 
large  number  of  a  resource  may  be  available,  md 
their  nunber  stored  as  part  of  the  state.  If  this 
is  done,  a  large  number  of  states  results,  sine-' 
each  possible  number  of  resources  rust  be  combine i 
with  every  other  facet  of  the  state.  Finch  tire  an 
Input  couses  ore  of  these  resource?  to  b* 

allocated,  the  next-state  is  one  that  indicate 3 


cm  less  of  the  resouce  than  the  present  state . 

As  an  alternative,  the  number  of  the  resource 
available  may  be  recorded  as  task  data.  However, 
this  number  docs  play  a  part  in  the  next-state  and 
output  decisions  whenever  it  is  zero,  and  must  be 
changed  each  time  one  of  the  resource  is  allocated 
or  returned.  To  make  this  possible,  two  sets  of 
algorithms,  input  and  output,  designated  IA  and 
OA,  are  added  to  the  finite-state  machine 
definition.  An  input  algorithm  is  used  upon 
receiving  an  input,  but  before  applying  the 
next-state  or  output  functions.  The  output 
algorithms  are  called  by  the  output  function.  An 
input  algorithm  has  access  to  the  input  and  task 
data  ,  and  cay  modify  the  input,  the  task  data  or 
the  state.  The  output  algorithm  has  access  to  the 
state  and  task  data,  and  may  codify  state,  task 
data,  or  output. 

The  resource  counting  example  may  be  handled 
with  an  output  algorithm.  Whenever  a  state  change 
occurs  that  causes  an  allocation  of  one  of  the 
resource,  an  output  algorithm  is  called  which 
decrements  the  counter  in  task  data,  and  tests  it 
for  zero.  If  it  is  zero,  the  algorithm  must 
change  the  state  to  indicate  none  of  the  resource 
remains.  Thus  the  possible  states  of  the  system 
include  a  substate  with  values  of  resource-present 
/  resource-absent,  but  not  with  values  of  each 
possible  number. 

The  fact  that  an  input  algoritm  may  change 
the  input  leads  to  the  definition  of  an  additional 
Input  set,  the  Modified  Input,  X'.  The  input  to  a 
program  may  have  thousands  of  possible  values,  but 
only  a  small  number  of  equivalence  classes  of 
these  values  cause  distinct  system  reactions. 
These  equivalence  classes  are  then  considered  to 
he  members  of  the  modified  input  set,  while  the 
actual  value  of  the  input  may  be  kept  in  task  data 
if  there  is  further  need  for  it. 

For  example,  an  input  cay  be  a  value  from  an 
analog  to  digital  converter.  The  occurance  of  an 
input  from  the  converter  is  in  the  input  set, 
while  the  value  itself  is  task  data  received  with 
the  input.  If  there  arc  three  ceaningful  ranges 
of  the  value,  say  less  than  10,  from  10  to  100, 
and  greater  than  100,  these  three  ranges  are 
■embers  of  the  nodi Tied  input  set.  An  input 
algorltho  is  called  each  time  a  value  is  received, 
which  produces  one  of  the  codified  inputs.  The 
■odified  input  is  used  for  the  next  state  and 
output  functions. 

A  second  exacple  la  that  of  an  input  which  is 
a  cooplex,  multi-field  record.  X'  should  not 
include  all  possible  values  of  this  record.  An 
appropriate  and  efficient  input  algorltho  may  be 
specified  by  a  decision  table,  where  the  actions 
of  the  decision  table  are  the  values  of  codified 
input  and  task  data  to  be  used. 

The  definition  of  a  finite  state  nachlne  as 
extended  here  is  summarized  as  follows: 


a  finite  set  of  states,  S, 


a  finite  set  of  Inputs,  X, 
a  set  of  task  data,  D, 
a  finite* set  of  codified  inputs,  X', 
a  finite  set  of  Input  algorithms,  1A, 
capping  X  and  V  onto  X',!>  and  S, 
a  next-state  function,  KS(x*,s),  capping 
X*  and  S  onto  5, 

a  finite  set  of  output  algorithms,  0A, 
capping  S,  D,  and  Z 
onto  S,  D,  and  Z. 
a  finite  set  of  outputs,  Z, 
an  output  function,  0(x',s),  capping 
X'  and  S  onto  Z  and  OA. 

Note  the  difference  in  the  use  of  decision 
tables  and  finite  state  machines  above.  Decision 
tables  are  used  where  the  decision  is  to  be  cade 
on  the  basis  of  new  and  unencoded  data  (for  table 
lookup).  Decision  tables  arc  converted  into 
programs  which  avoid  interpreting  all  fields  of 
the  record  if  possible  to  provide  either  memory  cr 
time  efficiency.  However,  when  the  data  upor: 
which  a  decision  is  to  be  cade  is  state  data, 
already  interpreted  at  earlier  events,  decision 
tables  lose  their  usefulness,  since  an  encoded 
state  nay  be  saved  and  used  directly  in  a  table 
lookup  scheme. 

The  objective  in  formulating  these  changes  in 
the  definition  of  a  finite  state  machine  is  to 
achieve  a  structure  which  allows  sufficient 
flexibility  to  preserve  practicality  ir.  diverse 
situations.  With  this  definition,  the  classical 
finite  state  machine  core  may  be  completely 
overshadowed  by  the  input  and  output  algorithms. 
Obviously,  this  is  not  the  intent.  The  input  and 
output  algorithms  should  be  used  only  where 
necessary,  and  the  next  state  and  output  functions 
should  be  used  as  the  primary  decision  making 
tool. 

Finite  State  Specification  ter-WWS 

A  Finite  State  Specification  Language,  FISSL, 
has  been  implemented.  The  primary  objective  of 
this  language  is  to  enhance  the  user's  ability  to 
specify  a  finite  state  machine  naturally  and 
efficiently,  and  to  understand  its  operation  onee 
specified.  An  intermediate  representation  of  the 
machine  is  saved  to  serve  as  input  to  the 
optimizer  and  other  system  programs. 

The  language  is  interactive,  in  which 
statements  are  interpreted  line  by  line  to  codify 
the  finite  state  machine  as  so  far  described.  The 
language  interpreter  responds  either  with  a 
diagnosis  of  error,  or  to  obtain  clarification  of 
allowable  ambiguities.  For  example,  the  use  of  a 
non-existent  state  would  be  an  error,  but  the 
respecification  of  a  table  entry  may  or  cay  not  be 
Intended  by  the  user,  so  clarification  must  be 
requested. 

In  the  description  to  follow,  numbers  in 
parentheses  Indicate  line  numbers  in  Figures  3. 
and  7.  The  line  numbers  are  not  part  of  FISSL, 
but  are  used  for  reference  only.  Disjoint  sets  of 
Danes  are  declared  for  the  input,  state  and  output 
sets  (1),  (2),  and  (3).  The  sets  of  names  are 


kept  disjoint  In  order  to  avoid  ambiguity  without 
demanding  an  ordering  of  names  by  type  or  use  of 
type  identifying  key  words  In  the  language 
statements.  The  declaration  of  the  input  and 
State  sets  cause  an' array  to  be  set  up  of  the 
proper  dimensionality  to  hold  the  next  state  and 
output  functions. 

The  statements  for  the  specification  are  . 
compact,  yet  logically  clear.  The  primary 
statement  Is  of  the  form 

FOR  <eondition  list)  DO  *<table  entry) 
The  condition  list  indicates  which  entries  in  the 
table  are  to  be  specified  by  this  statement.  The 
condition  list  2, C  in  (4)  specifics  a  single 
entry.  Omission  of  an  input  or  a  state,  as  in 
(5),  indicates  that  an  entire  row  or  column 
respectively  is  being  specified.  By  enclosing  a 
subset  of  inputs  or  states  or  both  in  parentheses 
It  is  indicated  that  the  cross  product  of  these 
subsets  is  to  be  specified.  For  example  (6)  shows 
the  condition  list  (2,3) , (/ ,C,E)  which  specifies 
entries  2, A,  2,C,  2,E,  3, A,  3.C,  3.E.  The  union 
of  several  of  the  above  entry  specifications  may 
be  achieved  by  separating  then  with  a  colon.  For 


example,  in  (11)  3,(D,E):1,C  specifics  the  entries 
3,D,  3.E,  and  1,G. 

The  Al.LDUT  operator  provides  easy 
specification  of  large  subsets  by  telling  what  is 
not  in  it.  For  cxaaple,  in  (9)  1 . (Al.I.V'JT  D,F.,G) 
Specifics  1 , A,  1,B,  1,C,  and  1,F.  (Tnis  example 
was  for  Illustration  rather  than  for  any 
specification  advantage.) 

The  table  entry  part  of  the  FOR  statement 
specifies  the  next  state  or  the  output  or  both  to 
be  filled  In  at  the  positions  specified  by  the 
condition  list.  In  (10)  only  the  next  state  C  is 
specified,  in  (9)  the  output  X,  and  in  (S)  the 
pair  F,X.  An  entire  entry  E3y  be  explicitly  made 
don’t  care  by  using  the  keyword  as  in  (7). 
Statement  (7)  is  restoring  2, A  and  ?,C  to  don't 
care  after  they  were  given  other  values  in  (6). 
This  is  an  example  of  where  a  request  for 
clarification  would  be  made. 

If  the  condition  list  consisted  cf  a  single 
row  or  a  single  column  only,  then  the  table  entry 
may  be  a  list  of  the  sane  length  as  the  row  or 


(1)  INPtffS  1.2. 3. » 

(2)  ?TATEi  A.F.C.D.E.F.G 

<j)  gir.i'ir's  x.r 

(4)  n.x  :.c.  to  f.x 

(5)  for  i  rot.A.c.nc.ac.E.E 
(»)  15?  (273)  ,(».c.rr  si  o.i 
(7)  F3R  2.(».C|  P0  'X 

(t)  r.«  :.e  £-,  r.\ 

(9)  To*'  l.(>r;.S!n  C.E.C):3,(F.G)  00  X 
CIO)  Fui  (o.i. >775  m  c 
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(13)  ICR  2.0:4, C  on  1,1 
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(14)  ISPPrS  SOK.A.SYN.OlE.STT.lTe.STI.rTX 

(15)  StauT  START .TST»n.Sl.tM>».ESOX 
{)»)  IaX".  si.p.o 

(17)  1'JFSTVICS  P-H.T.TT 
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(20)  FUR  H.ST.SYN  0  H.ST 

(21)  155  (TI.ST) .A'nn  TX.sior  r 

(22)  IcV  TX.SVN  ft'  SIN!. P 

(23)  1u5  (SY'Cl.SiN:),SYN~X1  STX:.4««T.  P 

(24)  KjR  (S1N1  .SVSil  ,A  [«1  It. Si'S  V 

(2$)  for  n x.syni ,syn:)7f.ts  (<">  i  os 
(2i)  Br  (T.Ti.T.STNi,T.si':7fi.<YN2).m 
on  enox 

(27)  FOR  (M.TXjH.SXNI ,lt.SYN:,4T ART) .SIX 

to  t.st 

(21)  tot  (tt.stni .tt.syn:) .a  rn  oc 
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IX)  TT.TX 
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(31)  9b»  (Tr.SYM.Ti .sy\:;.pef  m  tt.tx 

(34)  loh  TT.1x.0Ll  It)  n.sxs: 

(33)  FOR  TT.SYNl.SYN  |M  TT.ST 
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(36)  INPUTS  11,12 

(37)  States  si 

(54)  PART  SI  •  A.I.C.D.E 

(39)  SuPiTAHS  A  .  AI.A2.A3.A4 

(40)  Sill  ST  AY  IS  9  ■  91, S3 

(41)  SUEif'TtS  C  .  C1.C2.C3 

(42)  SUSSIAUS  0  -  01.02 

(43)  rrasiAUS  r  •  ri,.2 

(44)  CtriiT S  01.02.03, 111, OS.Ofc.OF 
(43)  CASE  l-.nn  FOR 

(46)  11  JO 

(47)  CASE  A  FOR 

(41)  AT  HOUR 

(49)  ELSE  03 

(50)  CASfA.I  I  OR 

(51)  AJ.F2  OO  A1.C2.01  00 

(32)  44.11  iy 

(S3)  04 

(34)  CASE  C  FOR 

(S3)  Cl  00  XI.C2.O1.07  00 

(56)  C2  TO  A1.CS.P2.P6  On 

(37)  C3  00  A2.0S  00  ‘ 

(39)  ELSt  ERROR 

<S9)  OH 

(60)  ilscTo  00 

(61)  93 

(92)  CASE  P  FOR 

(63)  01  TO  00 

(64  )  02  i«5  ~ 

(65)  0) 

(66)  CASE  l  FOR 

(67)  El  03 

(6t)  USE  TO  00 

(69)  00 

(70)  ELSE  TO  00 

(71)  02  ~ 

(72)  00 

(73)  SAHFlrxXAININC. 

(74)  00 

(73)  12  (It. 
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col iran.  This  allows  specification  of  a  whole  row 
or  column  consisting  of  arbitrary,  rather  than 
Identical,  entries  in  one  statement.  For  example , 
(5)  specifies  the  next  states  for  all  of  input  1. 

Any  table  entries  not  specified  in  any 
Statements  remain  don't  care.  Figure  *4  shows  the 
eanplete  finite  state  machine  specified  by  Figure 

3. 

Connound  States.  A  feature  # of  FISSL  that 
allows  coapact  specification  is  the  ability  to 
specify  cocpound  state  names.  A  state  may  be 
partitioned  into  several  substates,  each  of  which 
has  a  set  of  names  declared  for  it.  Ir.  Figure  5, 
the  state  set  is  initially  declared  to  have  five 
elements  in  05).  Then  (16)  partitions  state  SI 
into  P  and  D.  Elements  of  compound  names  are 
connected  by  a  dot.  (17)  and  (16)  declare  the 
elements  of  P  and  D  respectively.  SI  is  replaced 
In  the  state  set  by  the  cross  product  of  P  and  D. 
Since  none  of  the  ot.ner  states  declared  in  (15)  is 
partitioned,  they  remain  as  simple  states  in  the 
state  set. 

A  compound  state  name  may  be  used  in  a  FOR 
statement  in  the  same  manner  as  a  simple  state. 
Thus  (20)  illustrates  the  use  of  state  H.ST  in 
both  the  condition  list  and  table  entry.  The 
usefulness  of  compound  states  is  found  in  the 
ability  to  specify  multiple  states  by  leaving  out 
one  or  tore  of  the  substates.  This  is  interpreted 
in  a  condition  list  as  the  specified  names  with 
all  possible  names  of  the  unspecified  substates. 
In  (21)  TX  means  K.TX,  T.TX,  and  TT.7X.  ST  is 
similarly  combined  with  all  elements  of  P. 

When  one  or  more  substates  is  specified  in 
the  table  entry  part,  only  the  values  of  those 
substates  are  recorded  in  the  next  state.  The 
remaining  substates  retain  ar.y  previously 
speolfied  value.  In  some  cases,  the  desired  state 
change  consists  of  changing  only  one  of  the 
substates,  and  leaving  the  other(s)  unchanged  from 
their  present  state  value.  Leaving  such  substates 
unspecified  does  not  accomplish  this.  The  keyword 
SAME  followed  by  a  list  of  substates  causes  those 
aubstates  to  have  the  same  value  in  the  next  state 
as  It  has  in  the  present  state  for  each  entry 
specified  by  the  condition  list.  (21)  uses  SAKS  P 
to  the  table  entry  part.  The  condition  list 
specifies  all  states  with  TX  or  ST  as  values  of  0. 
These  states  are  to  have  a  next  state  of  TX  in 
aubstate  D.  Thus  U.ST.A  has  a  next  state  of  H.TX, 
while  T.ST.A  has  T.TX. 

Figure  6  shows  the  complete  state  table 
specified  b7  Figure  5.  This  state  table  specifies 
part  of  the  state  behavior  of  a  Half  Duplex 
Kon-swltchcd  Multipoint  Data  Communication  System 
originally  presented  with  a  flow  graph  by  BJorner 
C61. 

Case  Statement.  The  final  feature  of  FISSL 
is  a  procedure-like  CASS  statement.  It  is  called 
procedure-like  because  it  is  not  executed  at  run 
time,  but  at  compile  time  to  build  the  state  table 
much  In  the  manner  of  Parnas  (11).  Figure  7  gives 
an  example  of  the  use  of  a  case  statement.  It  has 


a  structure  quite  close  to  that  of  Figure  2, 
except  that  the  case  statements  may  "branch"  in 
more  than  two  ways.  The  outputs  01,  02,  etc.  are 
the  same  as  those  shown  in  Figure  2. 

CASE  statements  may  be  nested,  and  compound 
statements  grouped  by  £0  and  52.  The  form  of  the 
CASE  statement  is 

CASE  <condftion>  FOR 

<value1>  £5  <table  entry>  52 
<value2>  £5  <table  entry)  OP 


<valueN>  PS  <table  entry)  OP 
ELSE  £5  < table  entry)  CD 

<table  entry)  may  be  cither  a  table  entry  as 
described  above  or  another  CASE  statement. 
<conditicn>  has  the  same  form  as  a  simple 
condition  in  a  FOR  statement,  but  with  a  substate 
name  rather  than  a  substate  element  name,  and 
INPUT  rather  than  an  input  name.  The  keyword 
INPUT  causes  the  values  expected  in  the  CASE 
statement  to  be  input  values.  (45)  shows  a  nested 
case  statement  that  uses  If.'rUT.  Only  the  II  table 
entry  part  is  shown.  Figure  7  therefore  shows  the 
specification  of  one  column  of  the  state  tabic. 
(47)  causes  values  of  substatc  A  to  be  used. 

<value>  is  a  value  which  <condition>  may  take 
on.  Thus  In  (48),  if  A  has  the  value  A1  then  an 
error  routine  should  be  executed.  This  routine 
would  be  provided  by  the  uaer.  If  the  value  of 
the  present  state  Is  not  A 1 ,  then  the  table  entry 
is  specified  by  the  CASE  statement  at  (50).  This 
condition  expects  values  from  A.B.  Finally  in 
(51)  if  the  present  state  has  the  value  A2.B2  then 
the  next  state  has  A1  specified  for  A  and  C2 
specified  for  C.  In  addition  output  01  is' 
specified.  That  completes  the  evaluation  of  tht 
CASE  at  (51).  (61)  is  the  next  statement  grouped 
in  the  (49)  ELSE.  Therefore,  to  the  values  of  A 
and  C  is  added  the  specification  of  B3  for  B. 
Then  the  CASE  statement  of  (62)  uses  values  of  V. 
To  Illustrate  the  complete  operation  of  Figure  7, 
I1,A4.B1.C2.D2.E3  results  in  a  next  state  of 
A1.B3.C3.D1.E3.  The  E3  is  not  explicitly 
specified,  but  is  copied  from  the  present  state  by 
SAME  REMAINING  in  (73),  which  completes  the  next 
state  in  any  positions  not  yet  specified  in  an 
outer  CASE  statement.  Note  that  the  output  has 
resulted  in  a  string  of  outputs,  namely  04,06,02. 
Thus  the  CASE  statement  gives  the  ability  to 
specify  ordered  sequences  -f  outputs  as  the  result 
of  one  state  change.  Figure  8  shows  the  column  of 
the  state  table  built  by  repeated  execution  of  the 
CASE  statement. 

FISSL  as  described  here  only  allows  compound 
states.  Compound  inputs  arc  another  useful 
feature  that  is  not  included  here.  As  mentioned 
above,  the  CASE  statement  provides  compound 
outputs. 


6 


A  technique  recently  developed  [10]  Is  a 
■ethod  of  encoding  a  finite-state  machine  to  allow 
a  minimum  storage  expenditure  without  sacrificing 
real  time  advantages.  A  State  Table  Optimization 
Program  (STOP)  has  been  written  which  compacts  a 
state  table  into  a  set  of  minimal  input  subtables. 


The  actual  choice  of  Implementation 
Characteristics  to  be  optimized  are  not  as 
important  as  the  ability  to  produce  an  optimizer 
which  will  work  on  state  tables  of  a  more  useful 
size  than  may  be  handled  by  most  switching 
theoretic  techniques.  I  believe  that  useful  state 
tables  will  have  a  number  of  inputs  X  number  of 
states  product  in  the  range  50  to  1000.  Above 
1000,  the  complexity  of  the  function  being 
realized  calls  for  modularization,  just  as  large 
programs  must  be  modularized  to  keep  complexity 
manageable. 


The  characteristics  chosen  for  optimization 
are  real-time,  total  number  of  table  entries,  and 
number  of  bits  per  table  entry,  in  that  order. 
The  table  look  up  speed  of  a  two  dimensional  array 
is  not  to  be  sacrificed  for  memory.  Any 
optimization  technique  to  reduce  memory  usage 
should  preserve  the  inherent  speed  of  this 
technique  by  allowing  at  cost  a  simple 
transformation  of  the  state  to  a  table  Index,  so 
that  the  columns  cay  be  reduced  in  size. 


The  approach  taken  reduces  each  column  of  the 
state  table  to  an  input  sub-table  having  one 
unique  entry  for  each  distinct  specified  entry  in 
the  original  column.  Note  that  don't-cares 
(denoted  by  -  )  are  eliminated,  as  well  as 
redundant  occurances  of  entries  in  a  single 
column,  such  as  CX  in  column  1.  The  input  1 
column  in  Figure  3  has  four  distinct  entries,  as 
well  as  several  don't-cares  and  a  duplicate  entry. 
The  resulting  input  sub-table  produced  by  this 
approach  has  exactly  four  entries.  In  the  example 
of  Figure  3,  a  28  entry  table  is  condensed  to  four 
sub-tables  with  a  total  of  13  entries. 


The  method  used  to  cap  the  state  onto  a 
sub-table  index  is  to  assign  a  substring  of  the 
state  code  to  each  input.  These  substrings  should 
overlap  as  much  as  possible  to  keep  down  the  total 
oumber  of  bits  in  the  state  encoding.  The 
substring  is  used  directly  as  the  index  to  the 
Input  sub-table  associated  with  that  input.  Such 
s  capping  is  easily  pcrforced  on  cocputers  with 
logical  and  shift  instructions. 


The  optimization  depends  on  finding  an 
encoding  having  a  substring  for  each  subtable. 
Such  an  encoding  always  exist,  but  it  cay  have 
more  than  the  cinicum  number  of  bits  necessary  to 
uniquely  encode  the  state  set.  The  minimum  bit 
encoding  which  will  yield  13  entry  sub-tables  for 
Figure  3  uses  4  bits  rather  than  the  3  needed  to 
uniquely  specify  7  states. 


STOP  has  been  written  to  find  the  minimum  bit 
encoding  for  minimum  entry  input  sub-tables.  The 
algorithm  employed  is  a  highly  pruned, 


backtracking  search.  It  Is  based  on  an  extension 
to  the  partition  methods  of  iiarlmanis  and  Stearns 
[12]  which  allows  don't  cares  to  be  specified  as 
part  of  the  partition.  This  algorithm  is 

described  in  detail  in  [10]. 
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